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[57] ABSTRACT 

A bus transfer control system manages the transfer of 
multiple asynchronous data streams through a buffer pool. 
The bus transfer control system includes a buffer pool 
having a plurality of memory blocks, wherein each memory 
block provides for the storage of a plurality of data bytes and 
a plurality of data transfer devices coupled to the buffer pool 
to allow the transfer of segments of one or more data streams 
to be transferred between the plurality of data tranfer devices 
through the buffer pool. A transfer controller maintains 
status information relating to the status of data in the 
memory blocks and includes control logic for repeatedly 
evaluating (he status information and providing for the 
prioritied selection of a first data transfer device and a 
predetermined one of the memory blocks. 

12 Claims, 8 Drawing Sheets 
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MULTI-THREADED FIFO POOL BUFFER 
AND BUS TRANSFER CONTROL SYSTEM 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

The present application is related to the following 
Applications, all assigned to the Assignee of the present 
Application: 

1. Multiple Parallel Digital Data Stream Channel 
Controller, invented by Gifford, et al. Our ref.: DIAM 
3000 GBR. application Ser. No. 08/614.729, filed Mar. 
13. 1996. 

2. Distributed Status Signaling System for Multi-threaded 
Data Stream Transport Control, invented by Lewis, et 
al. Our ref.: DIAM3005GBR. application Ser. No. 
08/596.921, filed Mar. 13, 1996. 

3. Method and Apparatus Supporting Demand Driven 
Multiple Parallel Digital Data Stream Transport, 
invented by Spencer, et al.. Our ref.: DIAM3011GBR, 
application Ser. No. 08/615,682, filed Mar. 13, 1996. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention is generally related to high- 
performance peripheral data interfaces and, in particular, to 
a multi-threaded, bus-mastering, input/output (I/O) channel 
controller architecture applicable to general purpose per- 
sonal computers, computer workstations, and embedded 
communications and network data routing and conversion 
functions. 

2. Description of the Related Art 
The continuing development of typically multimedia. 

network and communications oriented applications for per- 
sonal computers and computer workstations is fundamen- 
tally dependant on performing computationally intensive 
operations on high data throughput digital data streams. 
Typically required computationally intensive operations 
include three dimensional (3D) audio generation and 
manipulation, wavetable based audio synthesis. V34 proto- 
col serial data signal generation and detection, and analog 
speech filtering and compression These operations, if imple- 
mented in software, will conventionally consume between 
20 and 40 million instruction cycles per second each (MIPS) 
when performed by the main or host processor of the 
personal computer or workstation system, la addition, sup- 
porting the associated high throughput data stream transfer 
to conventional peripheral coder/decoder chips (CODECs) 
will consume an additional one to two MIPS per digital data 
transfer stream. 

However, conventional microprocessors found in per- 
sonal computer and workstation systems are generally 
capable of upwards of only 60 MIPS sustained, and more 
typically 20 to 30 MIPS. Context switches, memory 
management, and peripheral wait states further operate to 
constrain the effective MIPS available to computationally 
process and transport digital data streams. Since, as a 
practical matter, significant host processor MIPS must be 
reserved for the execution of typically end-user applications 
concurrent with the performance of multimedia functions, 
the need for peripheral hardware support in processing 
digital data streams has been generally acknowledged 

In adding peripheral hardware support for mu lti m edia, 
network and communications applications, both hardware 
and software interface considerations need to be addressed. 
Any peripheral hardware used needs to be cost effective in 



5.784,649 

2 

adding computational functions without in turn, burdening 
the host processor with hardware service requirements. Any 
added support burden directly compromises the net effective 
MIPS gain obtained through the addition of the peripheral 
5 hardware. 

Similarly, the software interface to the peripheral hard- 
ware needs to efficiently interface with the operating system 
executed by the host processor to enable effective sustained 
use of the peripheral hardware. An ineffective software 
10 interface results in an increased MIPS commitment by the 
host processor to communicate with the peripheral hard- 
ware. Again, any increased processing burden due to com- 
plexities in managing the software interface to the peripheral 
hardware results in a direct reduction in the effective sus- 
is tained processing MIPS obtained by use of the peripheral 
hardware. 

Conventional approaches to providing peripheral hard- 
ware support for multimedia, network and communications 
applications include providing various combinations of 
20 dedicated integrated circuits (chips) implementing substan- 
tially hardwired or only partially configuration program- 
mable computational functions and highly software pro- 
grammable digital signal processors (DSPs). Dedicated 
function chips typically implement a limited signal process- 
25 ing function or small set of related functions in a low cost 
tightly packaged form. The supported functions are typically 
of specific functional scope and programmability is mostly 
restricted to initial configuration options and modest if any, 
dynamic controls, 
30 As a hardware peripheral, dedicated function chips typi- 
cally provide little or no direct support for managing con* 
tinuous real-time signal processing of digital data streams, 
let alone support for multiple data stream transport Such 
chips typically act as mere consumers or producers (sources 
33 or sinks) of a digital data stream that is pulled from or 
pushed to the chips at the available maximum or some 
desired rate determined by the host processor. Consequently, 
peripheral hardware utilizing dedicated function chips is 
subject to conventional data stream transfer interruptions 
40 and transport speed limitations due to. for example, exces- 
sive host processor interrupts, context switching, and vari- 
ous memory management kernel processing, as well as a 
fundamental competition for host processor CPU cycles 
with other applications being concurrently executed by the 
45 host processor. System wide competition or limited system 
hardware support for multiple logically concurrent direct 
memory access (DMA) data transfers will also reduce 
sustained data transfer rates to a dedicated function chip. 
Furthermore, the typically single stream nature of dedicated 
so function chips directly requires a substantial involvement by 
the host processor in performing data stream initialization, 
transport control and any required data stream mixing or 
multiplexing operations. Consequently, while dedicated 
function chips can provide a significant increase in the 
55 im 1 !* 1 '™*** 1 '* 1 and digital signal processing capabilities of a 
personal computer or workstation system, a substantial and 
generally unbounded processing burden remains with the 
host processor. 

General purpose digital signal processors have been 
60 implemented in peripheral hardware systems particularly 
where complex and high speed signal processing computa- 
tions are required. Conventional DSP chips are capable of 
providing upwards of 50 MIPS in a computational architec- 
ture well suited for data stream processing. In general, such 
65 DSP chips are relatively expensive and require relatively 
intensive software development programs to implement the 
software algorithms needed to perform their intended tunc- 
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dons. However. DSP chip architectures are generally not 
optimized for controlling extended data transfer operations 
or memory management functions. Rather, the architectures 
are typically optimized to read, process, and write data with 
respect to internal dedicated memory and external locally 
connected memory or directly connected dedicated function 
peripheral chips. Consequently, the host processor must 
again be substantially involved in data transfers to the 
memory space of a DSP implemented as peripheral hard- 
ware. Unfortunately, this generally results in the DSP being 
subject to the same limitations on the obtainable and sus- 
tainable performance of the host processor as in the case of 
dedicated function chips. 

In order to bound interruptions in the transfer of data to 
multimedia peripheral hardware, and thereby improve the 
sustainable data transfer rate obtainable from a host 
processors, a conventional operating system executed by the 
host processor may be augmented with a small, preemptive 
real-time kernel, such as SPOX. This kernel can be imple- 
mented as a low-level device driver supporting the real-time 
interrupt and data transfer requirements of the multimedia 
peripheral hardware. While such a real-time kernel does tend 
to ensure execution of maximum sustained data transfers to 
and from the DSP memory space, the host processor incurs 
the same substantial overhead of managing the data stream 
transfers as well as the additional execution overhead of the 
real-time kernel itself. 

Consequently, present multimedia, network and commu- 
nications peripheral hardware subsystems implemented 
typically for personal computers and workstation systems do 
not well address the need to efficiently provide additional 
processing capability through the addition of the peripheral 
hardware. 

Various host based signal processing architectures, such 
as native signal processing (NSP) and Direct-X, have been 
proposed and largely defined to address, among several 
objectives, the requirement that a well farmed software 
interface be provided to the operating system for 
multimedia, network and related communications opera- 
tions. A host based signal processing architecture relies on 
the specific use of the host processor itself to perform at least 
high level signal processing functions. Such architectures 
have at least two immediate benefits. The first benefit is that 
by significantly processing data streams before transport 
ultimately to peripheral hardware, the data streams are 
mixed, multiplexed or computationally reduced to lighten 
the processing overhead involved in the data transport to the 
peripheral hardware. Thus, the effective processing perfor- 
mance of the personal computer or workstation system may 
be slightly to significantly improved 

The second benefit is that a potentially comprehensive 
application programming interface (API) is presented to the 
operating system, thereby tending to virtualize particular 
implementations of the physical and functional peripheral 
hardware Multimedia, network and related communications 
applications can therefore effectively assume broader or 
simply different support for desired functions than actually 
provided by any particular implementation of peripheral 
hardware. Where direct support for a particular function is 
not directly provided by a particular instance of the periph- 
eral hardware, the function is performed in software by the 
host processor, executing as the host based signal processor, 
down to a functional level that is supported by the particular 
instance of the peripheral hardware. 

While host based signal processing can increase the 
efficiency of the personal computer or workstation system in 
performing multimedia, network and communications 



functions, many of the functions supported by host based 
signal processing are still quite cornputationally intensive. 
Thus, host based signal processing represents a most direct 
burden on the host processor. Furthermore, while host based 
s signal processing does have the potential for significantly 
reducing the volume of data transported to or from the 
peripheral hardware, as a practical matter the computational 
burden on the host processor will not be substantially 
affected and, in any event, will remain quite significant. 

10 

SUMMARY OF THE INVENTION 

Thus, a general purpose of the present invention is to 
provide a peripheral I/O controller supporting multiple, 
parallel variable bandwidth data streams over a high total 
15 bandwidth data transfer path established between a central 
processor and multiple multimedia, network and communi- 
cations related peripheral devices. 

This is achieved in the present invention through a bus 
transfer control system managing the transfer of multiple 
20 asynchronous date streams through a buffer pool. The bus 
transfer control system includes a buffer pool having a 
plurality of memory blocks, wherein each memory block 
provides for the storage of a plurality of data bytes and a 
plurality of data transfer devices coupled to the buffer pool 
23 to allow the transfer of segments of one or more data streams 
to be transferred between the plurality of data transfer 
devices through the buffer pool. A transfer controller main- 
tains status information relating to the status of data in the 
memory blocks and includes control logic for repeatedly 
30 evaluating the status information and providing for the 
prioritied selection of a first data transfer device and a 
predetermined one of the memory blocks. 

A computer system utilizing the multiple parallel digital 
data stream channel controller of the present invention can 
thus support the concurrent real-time transfer of a plurality 
of I/O data streams to and from an auxiliary data processing 
unit. The computer system can include a first processing unit 
including a first memory providing for the storage of a 
^ plurality of data streams characterized as each having a 
respective data transfer rate, a second processing unit pro- 
viding for the manipulation of data within data segments of 
the plurality of data streams, and the channel controller 
coupled between the first and second processing units to 
provide for the transfer of the plurality of data streams 
between the first and second processors. The channel con- 
troller provides for the selective transfer of data segments of 
the plurality of data streams based on the respective data 
transfer rates of the data streams. 

Thus, an advantage of the present invention is that it 
provides a dynamically allocated multi-channel control 
interface to a host processor system that, in turn, permits 
flexible programmability and control over the operation of 
the channel controller. 
53 Another advantage of the present invention is that it 
minimizes host processor performance loading by perform- 
ing substantial autonomous data transfer functions and 
dynamic flow management. The channel controller supports 
internal interrupt management that minimises both host and 
60 DSP interrupt support burdens, thereby enabling and sup- 
porting real-time multiple parallel channel signal processing 
through a comprehensive interrupt source managed data 
stream channel connecting the host with auxiliary signal 
processing units. 
65 A further advantage of the present invention is that it 
provides for the dynamic buffer sized, rate-controlled flow 
of multiple streams of data through the channel controller. 
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optimally utilizing the maximum available peripheral VO 
channel data bandwidth. Stream transfers are independent of 
stream data type. Each of the data stream channels of the 
channel controller exist as logically independent channels. 
The channels can be serially combined to provide discrete 
data routing paths through additional or on-board signal- 
processing circuitry as well as external peripheral signal 
processing units. 

Still another advantage of the present invention is that the 
provided autonomous bus master operation removes the 
requirement for conventional direct memory access opera- 
tion as well as host processor involvement in data transfers 
through the I/O channel controller. Interleaved transfer of 
segments of data streams enables the effectively concurrent 
parallel transfers of digital data streams to and through the 
channel controller. This substantially alleviates the need for 
host application context switches and most host user to 
interrupt kernel mode switches while providing real-time 
transport support for multiple concurrent data streams. 

A yet further advantage of the present invention is that it 
provides dynamic support of variable rate real-time time 
signal processing by ensuring effectively continuous flows 
of data between data sources and sinks at the dynamic data 
rate established by the stream peripheral for each data 
transfer channel. 

Yet still another advantage of the present invention is that 
it provides readily extensible support for auxiliary signal 
processing units including units that are fully programmable 
and others that provide only partially or even fully hardware 
implemented functions. 

A still further advantage of the present invention is that 
the channel controller is programmable as a composite 
function peripheral that effectively moderates computer sys- 
tem cost by greatly expanding the independent and coop- 
erative signal processing functionality of data intensive 
peripheral subsystems. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other advantages and features of the present 
invention will become better understood upon consideration 
of the following detailed description of the invention when 
considered in connection of the accompanying drawings, in 
which like reference numerals designate luce parts through- 
out the figures thereof, and wherein: 

FIG. In is a block diagram of a personal computer type 
system implementing a first enibodiment of the I/O channel 
controller sub-system consistent with the present invention; 

FIG. lb is a block diagram of an I/O channel controller 
sub-system consistent with a second embodiment of the 
present invention; 

FIG. 2 is a block diagram of a dedicated function embed- 
ded VO Channel, based system consistent with an alternate 
preferred embodiment of the present invention; 

FIG. 3 is a diagrammatic illustration of the software 
architecture relationship of an VO channel controller sub- 
system in relation with an operating system and multiple 
external hardware interfaces; 

FIG. 4 is a diagrammatic illustration of the high level 
control and physical data flow supported by an VO channel 
controller consistent with the present invention established 
in relation to an operating system; 

FIG. Sa is a detailed block diagram of a preferred embodi- 
ment of an VO channel controller of the present invention; 

FIG. Sb is a detailed block diagram of a preferred embodi- 
ment of a bus transfer control system of the present 
invention; 
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FIG. 5c is a detailed block diagram of a preferred CODEC 
embodiment of an integrated peripheral interface of the 
present invention; 

FIG. Sd is a detailed block diagram of an interrupt 
5 controller integrated peripheral of a preferred embodiment 
of the present invention; 

FIG. 6 is a detailed block diagram of a FIFO pool 
sub-system of an VO channel controller constructed in 
accordance with a preferred embodiment of the present 
10 invention; 

FIG. 7 is a detailed block diagram of a bus transfer unit 
controller sub-system of a preferred embodiment of the I/O 
channel controller of the present invention; and 

FIGS. 8o-c are control flow diagrams illustrating pre- 
l5 ferred modes of operation of an I/O channel controller based 
system consistent with a preferred embodiment of the 
present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

20 I. I/O Controller System Architecture 

FIG. la provides a block diagram of a computer system 
It. preferably implementing a personal computer 
architecture, that is coupled to a multi-function VO periph- 
eral controller hardware system (I/O channel controller) 22. 

23 A host processor 12. typically an Intel® Pentium® CPU. 
Motorola PowerPC® CPU. or the like, is coupled to a 
system main memory 14 via a processor bus 16. A conven- 
tional peripheral component interconnect (PCI) bridge inter- 
face 18 provides a high performance data and control 

30 connection between the processor bus 16 and a mezzanine 
PCI bus 20. The multi-function peripheral system 22 is 
coupled to the PCI bus 20 through a conventional PCI 
adapter bus connector 24. An I/O channel controller core 26 
that is centrally responsible for managing data and control 

35 signal transfers with respect to the PCI bus 20 is also 
coupled to the adapter bus 24. The VO channel controller 
core 26 operates as a substantially autonomous bus master 
peripheral controller supporting multiple concurrent data 
and control signal transfers between the PCI bus 2# and 

40 system 22. These concurrent transfers are preferably man- 
aged as independent pairs of data streams and control 
threads of execution where each stream is composed of 
discrete block transfers, consisting of one or more bytes of 
data, through the VO channel controller 26. Data blocks of 

45 concurrently supported streams are interleaved among one 
another to effectively establish concurrent stream data trans- 
port. 

In accordance with the present invention, the interleave of 
data blocks is determined by the controller sub-system 22 

50 and, in general, independent of the execution of the host 
processor 12. The interleave of data blocks implemented by 
the VO channel controller core 26 reflects the respective 
demand transport rates of the individual data streams as 
determined from the nature of the stream data transported. 

55 Consequently, where stream data represents a constant data 
frequency audio signal stream, the interleave of data blocks 
in the audio data stream may vary, though generally main- 
taining a fixed through-put rate reflective of the data stream 
transfer rate independently demanded by an audio stream 

60 coder/decoder (CODEC). Where the demanded data rate is 
not a constant such as where variable rate audio or video 
compression is utilized, the data block interleave may fur- 
ther vary though again in accordance with the demanded 
data transfer rate appropriate for the compressed data 

65 stream. 

In a preferred embodiment of the present invention, the 
I/O channel controller core 26 supports a number of directly 
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connected serial bus peripherals 2& These serial bus periph- By the implementation of the VO channel controller 26. 
ends 2$ preferably include dedicated function chips that contention for data transfers among the various serial and 
implement specific high speed, typically serially oriented parallel bus peripherals 28, 38. 40, 42 and digital signal 
data transport functions. A typical serial bus peripheral 28 processors 32. 36 is rninirnized The maximum data through- 
includes a dedicated function chip providing high speed 5 put supported by the multi-function peripheral system 22 is 
serial universal synchronous/asynchronous rate transfer effectively limited foremost by the available data transport 
(USAKT) function. Another possible serial bus peripheral 28 bandwidth between the Pa bus 20 and system memory 14. 
may implement a dedicated function chip set providing a A somewhat more practical limitation on the data 
low-cost hardware based audio sub-system. through-put supportable by the peripheral system 22 is the 
The I/O channel controller core 26 also preferably pro- 10 computational performance available from the digital signal 
vides a high speed, general data and control bus 30 in processors 32, 36. This limitation, however, can be over- 
support of a wide range of data processing and transport come in a number of different ways including increasing the 
peripherals. One or more digital signal processors (DSPs) number of digital signal processors coupled to the bus 30 
32. 36 and associated DSP RAM 34 can be attached to the and distributing the computational load among the paral- 
bus 30 to provide high performance computational support 15 lelled processors. Also, utilizing higher performance digital 
for indirectly attached peripherals, such as the serial bus signal processors will provide greater computational 
peripherals 28, a parallel bus peripheral 38 and the host through-put 

processor 12. Although dependant on the particular imple- Referring now to FIG. lb. an alternate preferred periph- 

mentation of the DSPs 32. 36. the DSP RAM 34 preferably eral system 44 is shown. The VO channel controller care 46 

exists internal to the DSPs 32, 36 and is mapped into an 20 provides enhanced support for the digital signal processor 32 

common address space accessible by the bus 30. The DSPs by further removing the digital signal processor 32 from the 

32. 36 preferably also provide interface control support for potentially time critical data transport path of the data 

directly connected peripherals, such as the serial bus periph- streams flowing through the serial bus peripherals 28 and, 

erals 40. 42. potentially, the parallel bus peripherals 30. Thus, while the 

The DSPs 32. 36 permit a variety of different computa- 25 digital signal processor 32 may process a data stream 
tional and control functions to be performed generally coupled directly through the serial bus peripherals 40, uti- 
independently and in-parallel with respect to one another. lizing the VO channel controller core 46 itself to control all 
Thus, for example, the digital signal processor 32 may data transfers between the serial and parallel bus peripherals 
implement a range of signal processing functions as appro- 28, 38 and the DSP RAM 34 removes many if not most of 
priate to support a variety of tdecommunications specific 30 the memory management and repetitive data transport tune- 
serial bus peripherals 40 Such a digital signal processor 32 tions from the digital signal processor 32. The DSP 32 is, in 
can implement signal processing algorithms that perform the turn, permitted to spend more time on computational opera- 
protocol and signal processing necessary to implement a dons rather than extended data transfer operations for which 
high speed fax modem, an integrated services digital net- the digital signal processor 32 may not be optimally suited, 
work (ISDN) connection, and a wireless data transceiver 35 Consequently, the digital signal processor 32 almost exclu- 
systems. The serial bus peripherals 40 directly connected to sively operates on data moved between the RAM 34 and 
the digital signal processor 32 can appropriately include a digital signal processor 32 using simple memory load and 
plain old telephone system (POTS) interface, an ISDN store operations. The subsequent transfer of data processed 
interface and a low-power FCC compliant RF or IR data by the digital signal processor 32 and stored in the RAM 34 
transceiver. 40 is transported to the serial and parallel bus peripherals 28. 38 

A second digital signal processor 36 can independently or without requiring any significant additional processing by 

cooperatively provide audio and video signal processing the digital signal processor 32. 

functions including 3D audio synthesis, wavetable based An embedded application of the present invention is 
audio signal generation and mixing, speech and music shown in FIG. 2. The system 10* may operate as an intelli- 
reproduction, and speech recognition. The serial bus periph- 45 gent stand-alone or remotely managed data stream proces- 
erals 42 directly connected to the digital signal processor 36 sor. An embedded processor 12*. such as an Intel 80196. and 
may then include appropriate CODECs and filters for per- a main memory 14*, preferably composed of a combination 
forming high speed bi-directional digital-to-analog signal of DRAM and Flash EPROM. are inter-connected by a 
conversions. processor bus 16". An VO channel controller core 26' sup- 
Parallel bus peripherals 38 are preferably connected 50 ports the transport of one or more potential overlapping data 
directly to the bus 30 to support high speed parallel tunc- streams between the processor bus \€ and an VO bus 30* . 
tions. The supported parallel function may include conven- One or more DSPs 32' and any number of network 
tional high speed bi-directional parallel data transfers, a peripherals, such as the network controllers 38, 38" are 
high-speed Ethernet-type network interface, as well as con- preferably attached to the VO Bus 30'. The DSP 32' can 
ventional ftor and SCSI interfaces to conventional disk 35 directly sendee interrupts generated by the network control- 
drives, CD-ROM drives, and the like. The parallel bus lers 38', 38" in support of their respective network data 
peripherals 30 may also include a direct or indirect interface stream transport functions. The DSP may utilize the VO 
through a video controller to the frame buffer of a video channel controller to actually control the transport of data 
display controller. An additional function of the parallel bus over the I/O bus 30* and. as desired, through to the main 
peripherals Is to provide a simple parallel/serial conversion 60 memory 14'. 

function via one or more serial control lines 41 connected In one preferred embedded embodiment, the embedded 
directly to a CODEC that is otherwise supported as a directly system 10* functions as an intelligent high-performance 
connected serial bus peripheral 42. As a practical matter, the network data router. The embedded CPU 12* executes a 
serial connection 41 permits relatively direct control access control program provided in the Flash EPROM of the main 
to the CODEC by either the other DSP 32 or more likely the 65 memory 14* that supports conventional SNMP router man- 
host processor 12 through a pass through connection to the agement functions, and data gathering and diagnostic func- 
tus 30. tions. The DSP 32' executes a control program from internal 
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DSP memory that is cither down-loaded from main memory 
14' by the embedded CPU 12 or is provided in Flash 
EPROM in or associated with Ihe DSP 32\ The DSP control 
program provides for the establishment and management of 
data routing and filtering trees within the DSP memory. As 
data packets are received by a network controller 38". source 
and destination packet data is passed to and processed by the 
DSP 32" against the routing and filter trees to determine 
whether and how to forward the packet Both the DSP 32* 
and embedded CPU 12' may be employed to perform 
protocol conversions and provide for the implementation of 
security protocols as desired 
IL Software System Architecture 

The operation of the VO channel controller in terms of 
data flow as related to the major components of the computer 
system 10 is shown in the diagram 50 of FIG. 3. An 
outbound stream of data effectively originates with an 
application program executed in conjunction with an oper- 
ating system by the host processor 12. Hie execution of an 
application within an application layer 52 results in a 
transfer of data 56 to a main memory storage space 54 within 
the memory 14. This data may be further manipulated under 
the direction of the application through the execution of the 
host processor 12 operating as a host-based signal processor. 
Thus, the data stream 60 may be iteratively transferred 
between the memory space 54 and the host signal processing 
layer 58. The particular signal processing actually per- 
formed by the host processor 12 is substantially determined 
by the various device drivers that together implement the 
mil or available functionality of the particular implemented 
host based signal processor API (HBSP API). Directly or 
indirectly. HBSP API calls are eventually resolved to calls to 
an 170 channel controller device driver that initiates a data 
transfer control thread to transfer the data stream 64 from the 
main memory space 54 to the I/O channel controller core 62 
for further transport and potential processing. Once the host 
processor 12, in executing the I/O channel controller device 
driver, has set up a control thread in the main memory space 
54 denning the data stream transfer 64, the host processor 12 
then operates to simply enable processing of the control 
thread on demand by the I/O channel controller 62. The I/O 
channel controller core 62 is thereafter responsible for 
actually performing the data stream transfer. 

The host processor establishes a control thread in the main 
memory space 54 by constructing one or more linked bus 
transfer unit (BTU) control blocks to associate the stream 
data as provided in the main memory space 54 with the 
control thread. The host processor 12. in execution of the VO 
channel controller device driver, initializes the I/O channel 
controller 62 with the initial BTU control block and pro- 
grams certain configuration registers of the I/O channel 
controller 62 to configure the selection of a particular 
routing of the data stream through the VO channel controller 
62. Thereafter, the host processor 12 does not participate in 
the actual transfer of the data stream 64 to the VO channel 
controller core 62. The data stream transfer is carried out 
under the direct control of the VO channel controller core 62 
as a bus master peripheral arbitrating with the host processor 
12 for access to the main memory space 54. Consequently, 
the initiation and continued performance of multiple parallel 
data stream transfers to the VO controller 62, as defined by 
respective control threads, are carried out effectively inde- 
pendent of one another and may be asynchronously initiated 
and completed by the I/O channel controller core 62. 

Each bus transfer unit at least implicitly specifies the 
destination of an associated data stream. A data stream may 
be directed to the RAM memory space of a digital signal 
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processor 68 or to a specific external hardware Interface 74 
of the various directly connected serial and parallel bus 
peripherals 28* 38. As a data stream 70 is processed by the 
digital signal processor 68. the resultant data 72 may be 

5 transferred to a directly connected external hardware inter- 
face 74 of a serial bus peripheral 40. 42. Alternately, 
resultant data may be stored back into the DSP RAM space. 
From the DSP RAM. the data stream 72 may be subse- 
quently transferred again by the digital signal processor to 
any directly connected serial bus peripheral 40. 42. 

Bus transfer unit control blocks that define a control 
thread for transferring the DSP RAM stored data stream 69. 
80 can be provided in either system main or DSP memory 
14. 34. Preferably, the DSP control thread bus transfer unit 
control blocks are established in system memory 14 by the 

15 host processor 12. Management of the DSP RAM 34 
memory space is performed globally by the host processor 
12 and thereby allows the DSPs 32. 36 to operate by 
definition independent of one another with respect to the use 
of the DSP RAM 34. 

20 The DSP bus transfer unit control blocks are defined to 
control the transfer of one or more data streams through and 
under the control of the I/O channel controller core 62 to any 
of the external hardware interfaces 74 of the serial and 
parallel bus peripherals 28. 38 that are directly connected to 

25 the VO channel controller 62. Alternately, the VO channel 
controller core 62 may be directed to pass the processed 
datastream 84 back to the main memory space 54 potentially 
for further processing by the host based signal processor 58 
or for use by an application 52. 

30 The digital signal processor 68 and VO channel controller 
core 62 receive inbound data streams 76. 82 from their 
directly connected external hardware interfaces 74. Where a 
data stream 76 is received directly by the digital signal 
processor 68. the data stream is preferably processed and 

35 stored to the DSP RAM 34. Subsequent transfers of the data 
so stored are coordinated by BTU control blocks provided 
preferably within the system main memory 14. This DSP 
BTU control thread directs the transfer of the data stream 69 
to the VO controller 62 for transfer as a stream 84 on to the 

AO main memory space 54 or to be redirected as a stream 80 to 
an the external hardware interface 74. 

An inbound data stream 82 from an external hardware 
interface 74 connected directly to the VO channel controller 
core 62 is redirected as a data stream 84 to the main memory 

45 space 54. Alternately, the data stream 82 may be directed as 
a stream 70 to the DSP RAM 34. In the latter instance, the 
data stream is typically processed by the digital signal 
processor 68 and provided either as a stream 72 directly to 
the external hardware interface 74 or as a stream 69 passed 

50 to the I/O channel controller 62 for return as a data stream 
80 to an external hardware Interface 74 or as a data stream 
84 to the main memory space 54. 

In general, an inbound data stream is ultimately routed to 
the main memory space 54. Once present in the main 

55 memory space 54. the data stream 60 may be further 
processed by the host based signal processor 58. Finally, a 
data stream 86 representing the fully processed inbound data 
stream maybe returned from the main memory space 54 by 
the operating system to an application program 52. 

60 The data stream management system 50 of the present 
invention thus provides multiple data paths that may be 
flexibly defined and iteratively traversed to efficiently obtain 
a maximum processing of multiple effectively parallel data 
streams through an ordered combination or sub-combination 

65 of the host based signal processor 58. I/O channel controller 
62. digital signal processor 68 and external hardware 
coupled through the external hardware interfaces 74. 
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Another view of the system 50, as shown in FIG. 4. 
illustrates die control and data flow paths established within 
the computer system 10 in accordance with the present 
invention. An application program layer 90 includes any 
number of co-executing applications 92, 94. These applica- 
tions 92. 94 make application programming interface (API) 
calls into an operating system layer 96 that includes a base 
operating system 98 and operating extensions including, 
typically, MIDI 100, TAPI 102. and speech API 104 oper- 
ating system extensions. Any number of additional or alter- 
nate APIs can be established within the operating system 
layer 96 consistent with, for example, the Direct-X API 
specification for Ring 3 operating system extensions. A 
memory block 106 is also shown as logically co-resident 
with the operating system 98 in the operating system layer 
96 for convenience. 

A device driver interface layer 108 includes the various 
Ring 0 device drivers needed to support the communications 
and data transfer between the operating system layer 96 and 
any components implemented as part of a peripheral layer 
114. In particular, the device driver interface layer 108 
includes an interrupt handler 110 and device driver 112 that 
provide, through execution by the host processor 12, support 
for an I/O channel controller 116 established within the 
peripheral controller layer 114. 

Finally, in accordance with the present invention, a con- 
troller peripheral layer 118 is provided. This controller 
peripheral layer 118 includes generally a digital signal 
processor 120, a memory 122 accessible by the DSP 120 and 
dedicated function external hardware 124 potentially acces- 
sible by both the DSP 120 and I/O channel controller 116. 

In a typical control flow, an Application A 92 establishes 
a data stream within the memory 106 through a conventional 
interaction with the operating system layer 96. As at least the 
initial portion of the data stream is constructed in the 
memory 106. the device driver 112 is called from the 
operating system layer 96 to prepare for a transfer of the data 
stream through the I/O channel controller 116 to the memory 
122 or external hardware 124 of the controller peripheral 
layer 118. The device driver 112 establishes one or more 
BTU control blocks within the memory 106 defining a 
control thread necessary to implement the data stream 
transfer. The initial BTU of the control thread is pro- 
grammed by the device driver 112 into the I/O channel 
controller 116 and a signal is provided to enable the opera- 
tion of the I/O channel controller 116 with respect to the 
programmed BTU. The operation of the I/O channel con- 
miller 116 is, thereafter, substantially autonomous in com- 
pleting the data stream transfer defined by the BTU pro- 
grammed into the I/O channel controller 116 and any other 
BTUs in the memory 106 that are part of the control thread 
defining the data stream transfer. 

Where the target of the data stream transfer is the memory 
122. the device driver 112 will first establish another series 
of one or more BTU control blocks within the memory 106 
to establish a control thread suitable for managing the DSP 
side transfer of a data stream The initial BTU is pro- 
grammed into the I/O channel controller 116 by the device 
driver 112. Next the device driver 112 may post a command, 
specifying the desired function of the DSP. to the digital 
signal processor 120. Preferably, this command is posted 
through the use of programmed I/O (PIO) into one or more 
registers maintained by the I/O channel controller core 116 
and readable by the digital signal processor 120 in response 
to a DSP interrupt signifying mat a command message has 
been posted. In response to the posted command, the DSP 
120 preferably initializes as necessary to perform the com- 
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manded function and then provides a signal 136 to the I/O 
channel controller 116 to enable the operation of the con- 
troller with respect to the pre-programmed BTU. 
In response to having two enabled BTUs that are at least 

5 implicitly linked together, the I/O channel controller 116 
initiates autonomous data transfers to retrieve a portion of 
the data stream defined by the host side BTU from the 
memory 106 directly 126. transiently store the data in an 
internal FIFO pool, and transfer the data autonomously to a 

10 sequence of locations in the memory 122 defined by the DSP 
side BTU. The autonomous operation of the I/O channel 
controller in accessing the memory 106 is preferably as a bus 
master device that participates directly in the memory cycle 
arbitration supported by the hardware bus management 

15 controller of the host processor 12 and PCI bridge interface 
18. As a consequence, essentially no execution cycles of the 
host processor 12 need be utilized in actually performing the 
data transfer 126. 
Execution cycles of the host processor 12 are effectively 

20 required to form the data stream in the memory 106 and, in 
typically executing the device driver 112, to initially estab- 
lish and manage the series of one or more host side and DSP 
side BTUs that define the control thread for the data stream 
transfer. However, the execution cycles required in the 

25 creation and management of the BTUs by the host processor 
12 are relatively minor in comparison to the execution 
cycles required to initially process and then store the data 
stream in the memory 106 under the control of an applica- 
tion 92, 94. Furthermore, the operation of the I/O channel 

30 controller 116 permits the formation of the data stream in the 
memory 106 to be loosely synchronous with the actual 
transfer of data 126 under the control of the I/O channel 
controller 116. Consequently, the limited execution of the 
device driver 112 by the host processor 12 in creation and 

35 management of host side BTUs need not be tightly coupled 
to the real time demand for data transfers through the I/O 
channel controller 116. 

The loose synchronism in the execution of the host 
processor 12 in support of the I/O channel controller 116 is 

40 further facilitated by the autonomous demand driven opera- 
tion and FIFO pool buffering functions of the I/O channel 
controller core 116 itself. The I/O channel controller core 
116 is autonomously capable of fetching successive BTUs 
from both the memory 106 and memory 122, though pref- 

45 erably only from the memory 106, as a data stream transfer 
proceeds. Thus, as the portion of the data stream controlled 
by a BTU is completed, the I/O channel controller core 116 
can fetch the next BTU in the control thread from memory 
and substitute the newly fetched BTU for the completed 

so BTU. Thus, an outbound data stream directed to the memory 
122 is transferred autonomously as long as successive 
source and destination control BTUs in the control thread 
are defined to provide for the ongoing transfer of the data 
stream. The rate that DSP side BTUs are completed, 

55 reloaded and re-enabled effectively reflects the data through- 
put rates demanded by the digital signal processor 120 in 
respective performance of each commanded function. 

A simpler mode of operation occurs when the data stream 
destination is the external hardware 124. The I/O channel 

60 controller 116 provides limited but adequate buffering for 
data transferred to the external hardware 124 via the data 
path 130. As the external hardware 124 demands data from 
the VO channel controller 116. a current BTU is utilized to 
control the transport of the data stream from the memory 106 

65 to the I/O channel controller core 116. As the external 
hardware 124 draws down on the available data buffered by 
the I/O channel controller core 116. the controller 116 
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autonomously operates to refill the buffer from a location in device driver 112 that permits programmed VO through to 

memory 106 defined by me current BTU. As the data the programmable registers of the external hardware 124. 

referenced by the current BTU is consumed by the external Concurrent with the initialization of the external hardware 

hardware 124, a next sequential BTU in the control thread 124, a BTU control thread is established in the memory 106 

is autonomously loaded by the VO channel controller 116 5 and an initial BTU is programmed into the I/O channel 

from the memory 106 in order to maintain the transfer of the controller core 116 and enabled to control the receipt of data, 

data stream 126 A data stream 130 is buffered directly into the VO channel 

Incoming data streams are handled in a generally similar controller core 116 at the externally demanded data transfer 

manner by the I/O channel controller core 116. A data stream rate. In turn, the I/O channel controller 116 autonomously 

received by the DSP 120 from directly connected external io operates to transfer the received data stream to the memory 

hardware may be processed by the DSP 120 and stored in the 106 under control of the current BTU. Again reasonably 

memory 122. Receipt of each incoming data stream is assuming that the I/O channel controller core 116 can 

anticipated by the host processor 12 and a corresponding transfer data to the memory 106 at a rate greater, though 

control thread of one or more DSP side BTUs is formed in preferably substantially greater, than that of the received 

the memory 106 with the initial BTU being programmed is data stream 130, data overrun is again effectively precluded, 

into the I/O channel controller core 116, subject to being m. I/O Channel Controller Architecture 

subsequently enabled by the DSP 120. A control thread of The general architecture of an 1/0 channel controller 140. 

one or more host side BTUs is also established in the constructed in accordance with a preferred embodiment of 

memory 106 again with the initial BTU being programmed the present invention, is shown in FIG. 5a. The I/O channel 

into the I/O channel controller core 116. Although empty. 20 controller 140 preferably employs three major internal 

this initial host side BTU is preferably set to an enabled buses, including a bus master program bus 142. a FIFO pool 

state. bus 144. and a PIO bus 146. The bus master program bus 

A command message, specifying the function to be per- 142 provides a communication channel between any number 

formed by the DSP 120. is then posted to a message storage of bus interface modules 148. 150 and a bus transfer control 

register within the I/O channel controller core 116. 25 system 170. The FIFO pool bus 144 is a dedicated bus for 

Preferably, the message is acknowledged by the DSP 120, typically high-speed burst data transfers between the bus 

the requested function is initialized, a potion of the exter- interface modules 148. 150. a FIFO pool 172 and any 

nally provided data stream is received and processed by the number of integrated peripherals and peripheral interfaces 

DSP 120 and stored in a known address block within the 174-188. The PIO bus 146 provides a general purpose 

memory 122. An enable signal 136 is then provided to the 30 programmed I/O communications path between the bus 

I/O channel controller core 116 to enable the initial DSP side interface modules 148. 150. the bus transfer control system 

BTU and allow for the autonomous transfer of the received 170. and the integrated peripherals and peripheral interfaces 

data stream. When the DSP side BTU specified data stream 174-188. A FIO bus access controller 151 operates as a PIO 

transfer has completed, the next DSP side BTU is loaded bus access arbiter between each of the bus interface modules 

into the I/O channel controller core 116 and left disabled 35 148. 150. 

Meanwhile, a next portion of the externally provided data Each of the bus interface modules 148. 150 serve to 

stream is received and processed into another known address connect the VO channel controller core 140 with a respective 

block within the memory 122 that is referenced by the next external communications bus. The host interface module 

DSP side BTU. Again, once this address block has been 148 serves to couple the I/O channel controller 140 to the 

filled with processed data, the now current DSP side BTU is 40 external PCI bus 20 while the DSP bus interface module 150 

enabled in response to the enable signal 136. In general, the similarly provides for an interface to the peripheral bus 30 

two address blocks in the memory 122 arc successively that connects to the external digital signal processor 32 and 

alternatingly used in successive alternation for the process- DSP RAM 34. 

ing of a single data stream. The host interface module 148 connects to the address. 
When me address block specified by me current host side 45 data, and control (A/D/C) lines 154 of the bus 20 and 
BTU in the memory 106 is filled by the processed incoming provides an external interface for an interrupt line 156 
data stream, the BTU is complete and the VO channel driven by an interrupt controller internal to the VO channel 
controller core 116 issues an interrupt 132 to the interrupt controller core 140. Within the host interface module 148, 
handler 110 that calls the device driver 112 to at least signal the address, data and control lines 154 connect to a host bus 
that the address block is available for host processing, so slave unit 158 and a host bus master unit 160. The host bus 
Preferably, a next BTU specifying another address block in slave unit 158 provides a conventional register based pro- 
the memory 106 is also autonomously loaded in an enabled grammed I/O interface to the PIO bus 146 so as to make the 
state by the I/O channel controller core 116 to continue the PIO bus 146 accessible to the host processor 12. The register 
receipt of the processed incoming data stream. interface also allows program access to and through the PIO 
Subject to the reasonable assumption mat the transfer of 55 bus 146 to programmable configuration and data registers of 
data between the I/O channel controller core 116 and the various units internally connected to the PIO bus 146. 
memory 106 is substantially faster than the rate that the DSP The host bus slave unit 158 also provides an externally 
can receive, process and store data into the memory 122. accessible register interface that permits programmed con- 
minimal but adequate buffering within the I/O channel trol of the host interface module 148. The host bus master 
controller 116 can ensure that demand driven transfer of the 60 unit 160 itself preferably includes the control logic appro- 
data stream 128 occurs without data overrun. priate to support conventional bus-master access arbitration 

The VO channel controller core 116 also provides data on the PQ bus 20. 

buffering for any data stream received directly from the The DSP bus interface module 150 similarly connects the 

external hardware 124. In general, the external hardware 124 address, data, and control lines of the DSP bus 30. The 

is enabled for operation in response to the host processor 65 address, data and control lines 162 connect to both a DSP 

execution of the device driver 112. The VO channel con- bus slave unit 166 and a DSP bus master unit 168. The 

troller core 116 preferably provides a register interface to the external interface for an interrupt line 164 driven by an 
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interrupt controller internal to the VO channel controller 
core 140 is also supported by the DSP bus interface module 
150. The DSP bus slave unit 166 provides a programmable 
register interface that allows for programmable control of 
the DSP bus master unit 168 as well as supporting general 5 
programmed I/O access between the bus 30 and the HO bus 
146. The DSP bus master unit 168 also includes control logic 
appropriate to permit conventional bus-master access arbi- 
tration on the DSP bus 30. 

Coordinated access to the PIO bus 146 by the host and 
DSP interface modules 148. 150 is controlled through the 
PIO controller 151. Each of the bus slave units 158. 166 
must arbitrate for exclusive access to the PIO bus and 
through to any of the interface registers accessible by way of 
the PIO bus 146. In addition, the host bus slave unit 158 can 
request a PIO bus bypass to be established by the PIO 15 
controller 151. A bypass data path is established from the 
host process 12. through the host bus slave unit 158. the PIO 
bus 146 and the DSP bus slave unit 166. The host processor 
12 is thus presented with a data path that allows all periph- 
erals accessible via the DSP bus 30 to be controlled directly 20 
by the host processor 12. This is useful in simplifying the 
control over the operation of some of the parallel bus 
peripherals 38. for example, to directly set or read the 
control mode of a CODEC 42. 

The bus transfer control system 170 operates as a central 
control system managing the transfer of burst data transfers 
between the host and DSP bus master units 160, 168, the 
FIFO pool 172 and the integrated peripherals and peripher- 
als interfaces 174-183 that are connected to the FIFO pool 
bus 144. The bus transfer control system 170 maintains a 
programmable table of BTUs. In the preferred embodiment 
of the present invention, the BTU table provides simulta- 
neous storage for 48 BTUs with each BTU occupying 16 
consecutive bytes of storage. Table I provides a description 
of the preferred BTU structure. 



TABLE I 
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Bits 


Address 






Transfer Length 
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Control Word 
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[15*] 


Reserved 




[31*] 
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The address field of a BTU structure defines the memory 
address used by the host and DSP bus master units 160. 168 
for the transfer of data between the system main memory 14 
and the I/O channel controller 26 and between the VO 50 
channel controller 46 and DSP RAM 34 As a data transfer 
proceeds, the address field value of the BTU is updated to 
maintain the address value as a proper memory pointer. 
Conversely, the transfer length value is decremented as the 
transfer proceeds to maintain an accurate reflection of the 55 
remaining transfer length described by the BTU. In the 
preferred embodiment of the present invention, the host 
address space is treated as a flat 32 bit address field. The 
address field for purposes of DSP bus master transfers may 
be differently defined As specified in Table n. a symmetric 60 
partition of the DSP RAM 34 can be readily enforced by 
definition of a high order bit or bits of the address field to 
selectively map the DSP RAM of multiple digital signal 
processors 32.36 or other peripherals 38 that might provide 
or utilize a discrete storage area within the DSP RAM 34 65 
into a common address space with respect to the I/O channel 
controller core 140. 



16 



TABLED 



Address 






(DSP only) 


T^cf nptirm 


Bit 


DSP 


DSP#1 or DSP#0 


31 


DM 


Data (1) or Program (0) Memory 


30 


Reserved 


Reserved for future use 


129:15| 


Address 


Byte Address 


115:0) 



The link descriptor field permits storage of an array 
pointer to a next sequential BTU in the current control 
thread. Preferably, the successive BTUs of a control thread 
not resident in the BTU storage space provided by the I/O 
channel controller 26 are stored in a table within system 
main memory 14, though BTUs can also be stored in DSP 
RAM 34. Where a BTU is stored in system main memory 
14. a two-byte host base link address value is separately 
stored in a configuration register of the I/O channel control- 
ler core 140. This host base link address, effectively the base 
address of the BTU table in system main memory 14* is 
concatenated with the current BTU link descriptor value to 
provide a memory reference to a next linked BTU stared in 
system main memory 14. Conversely, the BTU link descrip- 
tor alone is sufficient to provide the entire address specifi- 
cation needed to access a linked BTU stored in the DSP 
RAM 34. The link descriptor field is utilized in the autono- 
mous loading of a next linked BTU when the transfer length 
of a current BTU in the 170 channel controller core 26 is 
decremented to zero. Whether the link descriptor field is 
autonomously utilized to load a next BTU is determined by 
control bit values stored within a configuration control word 
register. Table HI defines the preferred definition of the 
control word register 



TABLE m 


Control Wad 


Description 


Bit 


Bus Mister 


Bus Muter from DSP/Host memory 


15 


Interrupt 




114:13] 


00 No Internet 






01 Host Interrupt 






10 DSPA Interrupt 






11 DSPS Interrupt 




Lmk Defined 


Link miomLatjoD is validfaot valid (Le. wait) 


12 


Link Master 


Link to BTU link table 


[11:10] 




00 No Link 






01 Link from Host 






10 Link from DSPA 






11 Link framDSPB 




Data Conversion 


Select data transformation diving transfer 


1*8] 


Burst Length 


Buret 32/not 16 bytes at a time 


7 


Direction 


Transfer fronVnot id the FIFO 


6 


Reserved 


Reserved for internal use 


5 


FIFO Number 


Select FIFO from FIFO pool 


14:0] 



Within the control word field, the bus master bit defines 
whether the BTU corresponds to a host-side or DSP-side 
control thread. The interrupt sub-field defines whether and to 
whom an interrupt will be ultimately issued upon decre- 
menting the BTU transfer length to zero. Encoding of an 
interrupt source vector and the actual generation of the 
external interrupt signal is controlled by an interrupt con- 
troller 18ft internal to the VO channel controller core 140. 
The link define bit specifies whether the link descriptor field 
maintains a valid value or not The link master sub-field 
stores the base address location of the BTU link table in 
system main memory 14. The data conversion sub-field 
encodes a data transformation to be applied to the data as 
transferred, such as byte order reversal or byte/word 
conversion. 
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The burst length bit selects between 16 and 32 byte burst 
transfer Lengths while the direction bit specifies the direction 
of the burst transfer. The FIFO number sub-fi eld se rves to 
identify the numeric identifier of a particular FIFO within 
the FIFO pool 172 that is to be used as either the source or 
destination of data transferred under the control of the 
current BTU. 

Finally, the status word field of a BTU. as detailed in 
Table IV. defines individual bits that reflect whether a 
specific BTU is busy, such as during a BTU update operation 
that is autonomously performed by the I/O channel control- 
ler core 26, and whether the BTU is both valid and currently 
available, or enabled, for participation in the arbitration for 
a bus master access. 



TABLE IV 


Sub-Field 


Descriptioo 


Bit 


Busy Bit 


BTU is busy trare&ning/lintiQg (Read Only) 


1 


BTU Enable 


Allows BTU to arbitrate for Bus Master 


0 



BTU table 192. The BTU scanner 196 operates to continu- 
ally scan enabled BTUs stored in the BTU table 192 for the 
purpose of staging BTU identifiers and related data in host 
and DSP staging registers within a internal register set 198. 
The preferred BTU register array definition is provided in 
Table V. 

TABLE V 
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Sub-Field 



Description 
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BTU Control 



Host Base Link Value 
Host Best BTU 
Host Current BTU 
Host Scan BTU 
DSP Best BTU 
DSP Current BTU 
DSP Scan BTU 



Reset, single step scan, enable, tnd 
remove valid for programming 



host BTU table ofiaet i 
best BTU register 
current BTU register 
scan BTU register 
best BTU register 
current BTU register 
scan BTU register 
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A multi-stage circular priority arbiter (CPA) is preferably 
implemented by the bus transfer control system 170 to 
continuously evaluate the currently enabled BTUs. The 
arbiter is coupled to the BTU table in a manner that allows 25 
direct identification of those BTUs that have their BTU 
Enable bit set. Within the identified set of enabled BTUs. the 
CPA operates to progressively select and stage BTUs for 
each of the host and DSP bus master units 160, 168. 

The core algorithm implemented by the CPA operates in 30 
response to the set of access requests, further constrained to 
the identified set of enabled BTUs. that exist in an arbitration 
cycle. All possible requestors are ordered left to right in 
basic relative priority. The CPA of the present invention 
provides additional qualifications on the priorities of the 35 
enabled requestors. Specifically, the winning requestor of 
the immediately prior arbitration cycle effectively has no 
priority in the current cycle. The first enabled requestor, if 
any. to the right of the prior winning requestor is pushed to 
the highest priority in the current arbitration cycle with 40 
priority decreasing further to (he right If no enabled 
requestor exists in the current cycle to the right of the prior 
winning requestor, then the basic left to right relative priority 
of the enabled requestors is used to select a current winning 
requestor. 45 

The decision matrix for the CPA is preferably imple- 
mented as a modified inverted binary tree. Additional con- 
trol logic is provided to maintain state information that 
identifies the winning requestor of the immediately prior 
arbitration cycle. Also provided is state information that so 
identifies the sub-trees that include the prior winning 
requestor and whether, at the lowest node in a sub-tree, the 
prior wining requestor is left or right relative to this lowest 
binary node. Consequently, an efficient mechanism is pro- 
vided to ensure substantially fair arbitration among all 55 
potential requestors. 

The bus transfer control system 170 is shown in greater 
detail in FIG. 5*. The bus transfer control system 170 
includes the circular priority arbiter 190. Individual access 
requests for access to the BTU table 192 are received via 60 
control lines 194 from the devices connected directly to the 
bus master program bus 142 and the HO bus 146. Data and 
BTU address portions of both the bus master program bus 
142 and PIO bus 146 connect to the BTU table 192 to allow 
the reading and writing of BTUs. The bus master program 65 
bus 142 also connects to a BTU scanner 196 that is treated 
by the arbiter 190 as continually requesting access to the 



Each access to the BTU table 192 is uniquely arbitrated 
through the operation of the arbiter 190. The bus master 
units 160, 168 each separately request access to the BTU 
table 192 whenever they are otherwise idle to obtain BTU 
stored data that will be programmed into the bus master unit 
160. 168 to define a bus master burst data transfer. The bus 
master units 160. 168 also request access to the BTU table 
192 following a burst data transfer to update the currently 
active BTU. 

The bus slave units 158. 166 are perrnittcd access to the 
BTU tabic 192 via the PIO bus 146. Such accesses are 
supported to typically allow the host processor 12 and DSPs 
32, 36 to program initial BTUs into the BTU table 192 and 
to subsequently enable the BTUs. The PIO bus 142 can also 
be used to permit the host processor 12 to examine the state 
of the BTUs as needed to monitor data transfer progress at 
a low level and to analyze error conditions should they arise. 

Essentially all other BTU table access cycles are made 
available to the BTU scanner 196. By considering only those 
BTUs that are enabled and thereby implicitly valid, the scan 
speed of the scanner 196 is maximized while reducing or 
mini mi ring the overall complexity of the scanner 196. As 
each valid and enabled BTU is scanned, the BTU scanner 
196 also obtains supporting FIFO flag status information via 
the FIFO flag bus 171 for the FIFO referenced by the BTU 
being scanned. Consequently, the BTU scanner 196 makes 
effective and efficient of all accesses to the FIFO flag store. 

Finally, the bus transfer control system 170 potentially 
generates interrupts depending on programmed controls 
upon each update operation of a BTU within the BTU table 
192. Whether a particular update operation will result in the 
issuance of an interrupt is determined by whether the update 
operation signals a bus master transfer error, a BTU transfer 
complete, and the programmable interrupt specification bits 
within the control word of the BTU being updated. If an 
interrupt is to be generated, it is issued via control lines 200 
to the interrupt controller internal to the VO channel con- 
troller core 26. 

Each BTU access arbitration cycle can be viewed as 
beginning when a BTU controlled bus master burst transfer 
completes by either the host or DSP bus master unit 160. 
168. The corresponding BTU is updated and a next BTU. 
selected as a product of prior arbitration cycle, is used as the 
source of data for programming a bus master unit 160. 168 
for the next bus master burst transfer. The data transfers 
specified by individual BTUs are not processed until 
complete, but rather segmented or partitioned on burst 
length boundaries and interleaved with the data transfers 
specified by other BTUs. 



02/12/2004, EAST Version: 1.4.1 



5,784,649 



19 



20 



The next BTU is immediately available for use in pro- 
gramming a bus master cycle due to the pre-staging of 
arbitrated BTUs. Thus . when a next BTU is staged down for 
programming into either the host or DSP bus master units 
160, 168. the circular priority arbiter operates to select and 
stage a new next BTU before the current bus master burst 
transfer completes. Consequently, the maximum potential 
data bandwidth supportable by the I/O controller is limited 
only by the potential bus master transfer speeds supportable 
between the I/O channel controller 26 and the system main 
memory 14 and RAM 34. 

Table VI describes the bus master programming address 
and control interface employed by both the host and DSP 
bus master units 160, 168. 

TABLE VI 



Bus Master Address Bus 


Descriptions 


Bit 


Address 


Start Address for Transfer 


[31 0] 


Bus Master Xfer Control 


Descriptions 


Bit 




jink rather dun transfer 


IS 


Transfer dons 


Send TD to FIFO after transfer 


17 


BTU done 


Send BTUD to FIFO after transfer 


16 


FIFO Byte Enables 


FIFO byte enables (encoded) 


[15:14] 


Burst 


Number of bytes to transfer 


[13:8] 


Data Coo version 


Bytes swapping during transfer 


[7:€] 




(from BTU) 




Direction 


Transfer framfaol the FIFO 


[*] 


FIFO Number 


FIFO from FIFO pool 


[4:0] 
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To program a bus master 160, 16$ for a data burst transfer, 
an address portion of the bus master program bus 142 is 
provided with the memory address for the data transfer as 
maintained in the address field of the BTU. A transfer 
control bus portion of the bus master program bus transfers 35 
the control signals described in Table V to the bus master 
units 160, 168. The link control bit will specify that the 
current bus master burst transfer is for data and not a 
changed or linked-to BTU. The transfer done and BTU done 
control signals allow stream status information to be effec- 
rivery encoded into FIFO data streams. The FIFO byte 
enables sub-field provides an encoded value of the ordered 
byte position of data within a four byte word that is being 
transferred in the current bus master data burst The burst 
sub-field specifies the number of bytes to transfer as part of 
the program burst data transfer. The data conversion sub- « 
field reflects the desired data conversion to be applied to the 
data transfer. The direction control bit identifies the direction 
of the burst data transfer. Finally, the FIFO number specifies 
the FIFO within the FIFO pool that is to participate in the 
burst transfer. 

Once programmed, the host and DSP bus master units 
160; 168 autonomously operate to arbitrate for and perform 
sufficient bus access cycles to carry out the programmed 
burst data transfer. Where the burst data transfer is into the 
I/O channel controller 26, the burst data is temporarily 
stored in a FIFO within the bus master units 160, 168. A 
separate, request acknowledge arbitration is then performed 
by the bus master units 161. 168 to gain access to and 
through the FIFO pool bus 144 to the FIFO pool 172. Data 
from the internal FIFOs is then transferred to the FIFO pool 
172 and specifically to the FIFO specified by the FIFO 
identifier of the current BTU. 

For data that is outbound from the I/O channel controller 
26. the bus master units 160, 168 initially arbitrate for access 
to the FIFO pool 172 and pre-load their internal FIFOs with 
the burst length number of bytes from the FIFO specified by 
the BTU provided FIFO identifier. An autonomous bus 
master operation then proceeds to perform a burst data 



transfer from the internal FIFOs out from the host or DSP 
bus master units 160, 168. 

A slightly different programming of the bus master units 
160, 168 is utilized to retrieve a linked to next BTU in 
autonomously continuing, or at least preparing to continue 
either a host side or DSP side control thread. On completion 
a full data transfer specified by a BTU with a valid and 
enabled link descriptor, the BTU is cycled through the 
circular priority arbiter until the BTU is again selected to 
control a bus master burst data transfer. The zero transfer 
length of the BTU causes the link descriptor to be passed via 
the low order portion of the bus master program bus to the 
host or DSP bus master unit 160. 168. as appropriate. Where 
the BTU is stored in system main memory 14, the high order 
address portion of the bus master program bus is used to 
simultaneously provide the host based link descriptor to the 
host bus master unit 160. The BTUs in the RAM 34 are 
stored within the address scope of the link descriptor alone. 
In all events, the link control hit is set to signal that a 
linked-to BTU transfer burst is being programmed. 
Preferably, the internal FIFOs of the host and DSP bus 
masters 160, 168 have a depth at least equal to the size of a 
BTU. Thus, a single bus master burst transfer can be utilized 
to retrieve the desired BTU from either the system main 
memory 14 or DSP RAM 34. Once the desired BTU has 
been stored in a bus master internal FIFO, the host or DSP 
bus master unit 160, 168 requests access to the bus master 
program bus 142 to transfer the BTU to the bus transfer 
control system 170. Access is requested by the assertion of 
a request control signal on the bus master program bus 142. 
An acknowledge signal generated by the bus transfer control 
system 170 grants unique access to a word-wide update/link 
data bus 173 provided generally in connection with the FIFO 
pool bus 144. 
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TABLE VII 


FIFO Update Bus 


Descriptions 


Bits 


Update FUg 


mA'^^* ao Update cycle 


1 


FIFO Number 


□umber of the FIFO being updated 


5 


Read Size 


□umber of data bytes in FIFO 


6 


Write Size 


number of open bytes in FIFO 


6 


Read Byte Enables 


read byte selection within FIFO 


4 


Write Byte Enables 


write byte selection within FIFO 


4 


BTU Done 


BTU Done Sag to Flag Store 


1 


Transfer Done 


irij**^* transfer done 


1 


Space Available 


is space available in die FIFO 




Data Available 


b data available in the FIFO 


I 



A two-bit bus master link address bus is driven by the bus 
transfer control system 170 to coordinate the preferably 
three update/link data bus access cycles necessary to transfer 
the complete BTU to the BTU table within the bus transfer 
control system 170; the fourth byte is currently reserved and 
not transferred. Hie effectively linked-from BTU is over- 
written with the linked-to BTU. The location in the BTU 
table of the current BTU is maintained by the bus transfer 
control system to permit a status update operation on the 
BTU following each bus master burst data transfer. Where 
the current BTU is also a linked-from BTU, the update 
operation directly provides for the in-place overwriting of 
the linked-trom BTU with the linked-to BTU. The linked-to 
BTU is then cycled into the ongoing arbitration operation of 
the circular priority arbiter. 
IV. Distributed Status and Control System 

The bus transfer control system 170 generally serves to 
manage the transfer of data through the bus master interfaces 
148. 150 with respect to the FIFO pool 172. However, the 
FIFO pool 172 itself implements access control logic that 
serves to centrally control the grant of data access cycles to 
the FIFO pool bus 144. As detailed in Table VTL the FIFO 
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pool bus 144 preferably includes a 32-bit wide data bus, a 
five-bit wide address bus, and unique access request and 
grant control lines that allow each of the bus master inter- 
faces 148. 150 and the integrated peripherals and peripheral 
interfaces 174-182 to individually request access to the 
FIFO pool bus 144 and to receive individual access 
acknowledged signals. 



TABLE VIE 



FIFO Pool Bus 


Descriptions 


Bits 


Request 


request lines for FIFO pool access 


10 


Request Done 


last request to FIFO pool for this transfe 


r 10 


Acknowledge 


acknowledge lines for FIFO pool access 


10 


FIFO Number 


number of FIFO being accessed 


s 


Byte Enables 


byte selection within FIFO 


4 


Data la 


data from device to FIFO pool 


32 


Data Out 


data from FIFO pool to device 


32 


Direction 


data transfer direction 


1 


BTU Done 


BTU Done flag to Flag Store 


1 


Data Available 


is data available hi the FIFO 


1 



Associated with and generally part of the FIFO pool bus is 
the FIFO update bus (Table VI). The FIFO update bus 
preferably includes a five-bit FIFO status bus that is used to 
broadcast the FIFO identifier of a FIFO within the FIFO pool 
172 to at least all of the integrated peripherals and peripheral 
interfaces 174-183 that are coupled to the FIFO pool bus 
144. A FIFO identifier is broadcast over the update bus 
whenever data is added to or drawn from the corresponding 
FIFO in the FIFO pool 172. By effectively broadcasting 
notice of changes in the state of the FIFOs within the FIFO 
pool 172, the FIFO pool implicitly simplifies the necessary 
operation of the circular priority arbiter implemented within 
the FIFO pool 172 as well as the corresponding control logic 
necessary within each of the integrated peripherals and 
peripheral interfaces 174-183. 

Distributed control logic is provided with each of the 
integrated peripherals and peripherals interfaces 174-183 
that connect to the FIFO pool bus 144. Each of these 
integrated peripherals and peripherals interfaces 174-183 
are preferably programmable with one or more FIFO 
identifiers, corresponding to the number of FIFOs in the 
FIFO pool 172 that arc needed to support their respective 
functions. Each FIFO supports a unidirectional data stream* 
so pain of FIFOs are required for full-duplex communica- 
tion. The distributed logic in each of the integrated periph- 
erals and peripheral interfaces 174-182 monitors the FIFO 
identifiers broadcast over the FIFO status bus for matches 
with their pre-programmed identifiers. When an identifier 
match is found, the integrated peripheral or peripheral 
interface 174-183 may men issue a control signal request for 
a data transfer cycle on the FIFO pool bus 144. A unique 
acknowledge signal is subsequently issued by the FIFO pool 
172 to grant access to the FIFO pool bus. Thus, the circular 
priority arbiter of the FIFO pool 172 need only consider 
access requests from integrated peripherals and peripheral 
interfaces 174-183 for which a real data transfer can be 
performed. Furthermore, as there may be any number and 
combination of types of integrated peripherals and periph- 
eral interfaces 174-183. the circular priority arbiter of the 
FIFO pool 172 is effectively isolated from needing to 
consider any specialized aspects of a data transfer cycle 
requested by any particular one of the integrated peripherals 
and peripheral interfaces 174-183. Specifics of operation 
that might affect the appropriateness of requesting a memory 
access cycle on the FIFO pool bus 144 is managed internally 
by each of the integrated peripherals and peripheral inter- 
faces 174-182 as appropriate to their specific function. 
Consequently, substantial portion of the access determina- 
tion and arbitration control logic is effectively distributed 
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throughout the VO controller 140. The control logic asso- 
ciated with the circular priority arbiter of the FIFO pool 172 
need not be fundamentally or even significantly modified 
should the type, number or function of any of the integrated 
peripherals or peripheral interfaces 174-183 change 
between different specific implementations of the I/O chan- 
nel controller core 140. 
V. Integrated Peripherals and Interfaces 

The integrated peripherals and peripheral interfaces 
174-188 each preferably present a register based interface 

10 via the FIO bus 146 to the remainder of the VO channel 
controller cere 140. Each of these register interfaces are 
thereby accessible by the host processor 12 and digital signal 
processors 32. 36 by way of the host and DSP bus slave units 
158. 166. Hie register interface to the PIO bus provided by 

15 each instance of the integrated peripherals and peripheral 
interfaces 174-188 may vary from simple to significantly 
complex In general, the register interface is required to 
permit programming of the desired operation of the periph- 
eral 174-188. to permit a reset of the peripheral 174-188. to 

2Q specify the conditions upon which interrupts may be gen- 
erated and the external processor to which the interrupt will 
be issued, and. where the peripheral 174-183 also connects 
to the FIFO pool bus 144. storage for a FIFO identifier for 
each concurrent data stream supportable by the particular 
peripheral 174-188. 

M In addition, each of the integrated peripherals and periph- 
eral interfaces 174-183 include a data staging FIFO provid- 
ing for the transient storage of data being transferred to or 
from the FIFO pool bus 144. Preferably, the depth of this 
internal FIFO is sufficient to protect against data under-runs 

30 and over-runs in view of the throughput data rate anticipated 
to be supported by the integrated peripheral or peripheral 
interface 174-183 and the worst case bus data transfer 
latency between the FIFO pool 172 and particular integrated 
peripheral or peripheral interface 174-183. Where the 

35 anticipated data transfer rate through an integrated periph- 
eral or peripheral interface is sufficiently low. the internal 
FIFO may be implemented simply as a single buffer register. 
Peripheral internal FIFOs are. however, typically two to four 
bytes in depth. 

w A preferred MIDI interface peripheral interface 174 
implements a relatively simple register interface to the PIO 
bus 146. The preferred control registers implemented by the 
MIDI interface peripheral 174 include a transmit control 
register and a receive control register. The register interface 
is detailed in Table DC. 



TABLE DC 
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MIDI XMit Control Register 


Descriptions 


Bit 


Reserved 


Not used or test values 


131-71 


Transmit Eusble 


Enable MIDI transmit 


6 


Reset 


Reset the MIDI transmit port 


5 


FIFO Number 


FIFO from FIFO pool 


1*01 


MIDI Receive Control Register 


Descriptions 


Bit 


Reserved 


Not used or test values 


[31:101 


Interrupt Select 


00 => no interrupt generated 






01 => interrupt bost CPU 






10 => interrupt DSP 1 






11 => interrupt DSP 2 




Receive Enable 


Eaabke MIDI receirCT 


7 


Reset 


Reset the MIDI transmit port 


6 


FIFO Number 


FIFO from FIFO pool 


[SO] 



The transmit control register includes a five bit FIFO ID 
field, a reset bit and a transmit enable bit The receive control 
65 register preferably includes a five bit FIFO ID field, a reset 
bit, a receive enable bit, and a two bit interrupt field that 
encodes whether an interrupt is to be generated in response 
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to an error condition coincident with the receipt of a data 
byte ox word through the external interface or MIDI inter- 
face peripheral 174 and. if so, the intended destination of the 
interrupt Interrupts are preferably generated by this periph- 
eral 174 only on error conditions. Logically connected 
immediate transfer ports are preferably used to generate data 
transmittedAeceived interrupts that serve to control the flow 
of data through the MIDI interface peripheral 174. 

The register interface to the CODEC peripheral interface 
176 may be significantly more complex than that of the 
MIDI interface 174. Where a conventional external CODEC 
is to be attached to the CODEC interface 176. the register 
interface needs to provide access to the control and data 
registers of the external CODEC itself. Alternately, the 
CODEC peripheral interface 176 may itself implement part 
or all of the functionality of a conventional CODEC, thereby 
limiting the required external components connected to the 
CODEC peripheral interface 176 to comparatively minirnal 
analog components. In this latter instance, the CODEC 
interface 176 is men a fully integrated peripheral that 
directly presents CODEC control registers to the PIO bus 
146. In either instance, the CODEC interface 176 includes 
the logic necessary to permit the CODEC interface 176 to 
arbitrate for access on the FIFO pool bus 144 and to monitor 
for changes in the status of a FIFO pool 172 FIFO corre- 
sponding to a FIFO identifier programmed into a register of 
the CODEC interface 176. 

FIG. 5c shows the preferred implementation of the 
CODEC interface 176 as used to support an external 
CODEC, such as an Analog Devices 1843 CODEC. The 
essential CODEC interface data path and control logic 180 
provides support for multiple, essentially bidirectional data 
streams to be passed over the data portion of the FIFO pool 
bus 144 between respective pairs of FIFOs potentially 
allocated within the FIFO pool 172 and FIFO pairs internal 
to the CODEC interface 176. Preferably up to four outbound 
data streams are buffered through four internal FIFOs 
210-212. A data multiplexer 216 provides for the selection 
of eight or 16-bit data variously from the FIFOs 210-214 in 
correspondence with the control mode established in the 
external CODEC. The byte or word data stream is passed 
through a clocked latch and serializer 218 under the control 
of a register interface and I/O control unit 220. Clock and 
control signals are provided by the register interface and VO 
control unit 220 via the clock and control lines 222. The 
register interface and VO control unit 220 coordinates the 
transfer of data with the external CODEC through the 
exchange of clocking and control signals on lines 224. Thus, 
subject to the operation of the register interface and VO 
control unit 220. serialized data is provided on a serial data 
out line 226 to the external CODEC. 

CODEC mode commands and command related data are 
also provided to the external CODEC on the serial data out 
line 226. Mode commands and data is preferably provided 
via the PIO bus 146 to the register interface and VO control 
unit 220. The mode commands and data are then routed, via 
lines 214. through the multiplexer 216 and latch 218 while 
a command mode transaction is signaled via lines 224. 

Serial data from the external CODEC is received on line 
226 by a clocked de-seriaHzer and latch 230. Depending on 
the current command mode of the external CODEC, status 
information and related data is provided through a 
de-multiplexer 232 and over lines 234 to the register inter- 
face and VO control unit 220. Other byte or word wide data 
is provided from the de-multiplexer 232 selectively to any of 
four internal FIFOs 236-238 under the control of the register 
interface and I/O control unit 220. 

The register interface and VO control unit 220 also 
provides the request and acknowledge control logic to 
support data transfers over the FIFO pool bus 144. Tike 
register interface and VO control unit 220 preferably pro- 
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vides register storage for up to eight FIFO identifiers. Each 
FIFO identifier permits a particular in ternal FIFO to be 
uniquely associated with any one of the FIFOs in the FIFO 
pool 172. The FIFO update portion of the PIO bus 144 is 
continually monitored by the register interface and VO 
control unit 220 to identify when the status of an identified 
FIFO changes, Tlie register interface and VO control unit 
220 typically issues a FIFO pool access request on behalf of 
the internal FIFO whose FIFO identifier matches the FIFO 
identifier broadcast over the update bus. 
10 The FIFO identifier registers and other CODEC interface 
control registers arc accessible typically by the host proces- 
sor 12 via the PIO bus 146. The preferred CODEC register 
interface presented to the PIO bus 146 is provided in Table 
X. 

15 TABLE X 



CODEC Registers Descriptions Bit 



35 



40 



Master Control 




1151 


Audio Command 


mmmt nH fO Audio CODEC 


114:91 


Audio Data 


mode set data to Audio CODEC 


[8:3| 


Telephony Command 


command to Telephony CODEC 


2 


Telephony Status 


mode set data to Telephony CODEC 


1 


Status Command 


read-only CODEC status bits 


8 


Status Data 


readonly mode set data 




FIFO Number 0 


FIFO enable bit and pool cumber 


8 
8 


FIFO Number 7 


FIFO enable bit and pool cumber 


8 


Clock 


clock counter control 


16 


Host Mask 


host interrupt mask value 


12 


DSP Made 


DSP interrupt mask value 


12 


Interrupt Control 


transfer done, under/or er run bits 


12 


Master Control 


Descriptions 


Bit 


CODEC Reset 


resets all CODEC related logic 


[13] 


DAC Mode 


set DAGO,! operating modes 


(MSI 


ADC Mode 


set ADCO.1 operating modes 


[8:31 


Audio Enablo 


audio CODEC reset 


2 


Telcpbopy Enable 


telephone CODEC reset 


1 


CODEC Identifier 


type of external CODEC 


0 


Interrupt CuuUol 


Descriptions 


Bit 


Transfer Done FIPO 0 


transfer done interrupt bit 


1 


Transfer Doue FIFO 3 


transfer done interrupt bit 


1 


Under Run FIFO 0 


under run interrupt bit (DAC1) 


1 


Under Run FIFO 3 


under run interrupt bit (DAC4) 




Over Run FIFO 4 


over run interrupt bit (ADC 5) 


1 


Over Run FIFO 7 


over run interrupt bit (ADC8) 


1 



A joystick peripheral and potentially associated control 
console may be supported through the digital joy stick 

50 interface 178. The peripheral joy stick typically provides 
resistances that are proportional to the physical position of 
the joy stick. The digital joy stick interface 178 preferably 
implements a timer and capacitor that, combined with the 
resistances presented by the joystick peripheral, permit 

55 digital values representing the position of the joystick to be 
repeatedly developed autonomously by the digital joystick 
interface. The host processor 12 is thereby relieved of the 
need to set and function as a timer to determine the position 
of the joy stick. Preferably, the digital joy stick interface 174 

60 can be programmed to signal an interrupt that is passed to 
the host processor 12 or a DSP 32. 36 whenever the 
determined digital values change. Even where an interrupt is 
not generated, roe digital values arc continually made acces- 
sible via the PIO bus 146 through the register interface 

65 presented by the digital joy stick interface 178. 

Depending on the configuration and data requirements of 
any associated control console, as may be developed in 
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support of various gaming and control applications, a data 
stream may be passed through the FIFO pool 172 and digital 
joystick interface 178. Where the data stream transfer rate is 
generally low and latency is a issue, a logically connected 
Immediate transfer port is preferably used to generate inter- 
rupts to the host processor 12 or either of the DSPs 32, 36 
as data is transferred to or from the digital joystick interface 
178. Where latency is not a significant issue or where the 
required data rate is relatively high, full bus master data 
transfers through the FIFO pool 172 can be used. 

Another type of integrated peripheral or peripheral inter- 
face is represented by the general purpose interface ports 
180. In a preferred embodiment the interface ports 180 may 
implement a high speed, very wide parallel port suitable for 
interfacing to video controller or directly to a video frame 
buffer. Successive double word wide data transfers from the 
FIFO pool bus 144 may be buffered into a 64 bit 128 bit or 
larger words mat are transferred in parallel to the video 
controller or frame buffer. In this instance* one or more video 
words may be register buffered within the interface port 180 
so as to permit an optimal matching of the timing of the word 
transfer to the controller or frame buffer. 

The interface ports 180 may also be utilized to read a 
video controller or frame buffer at high speed. One, though 
preferably two or more frame words may be read in suc- 
cessive parallel read operations from the video controller or 



available in the identified FIFO. The second imnwlfatft 
transfer port is programmed to emit a DSP interrupt when- 
ever data is available in the same identified FIFO. To initiate 
the data stream transfer and subsequently in response to host 
s interrupts, the host processor 12 provides for the transfer of 
data through the host bus slave unit 158 and the PIO bus 146 
to the I/O data register of the immediate transfer port 
associated with the host processor 12. The immediate trans- 
fer port places the received data in the identified FIFO of the 
10 FIFO pool 172. 

In response to the FIFO identification broadcast by the 
FIFO pool 172 on the FIFO status bus. the second immediate 
transfer port issues a DSP interrupt. In response, a DSP 32, 
36 accesses the I/O data register of the immediate transfer 
15 port. Data is read from the FIFO in the FIFO pool 172 and 
transferred to the DSP 32. 36 to be processed and. typically, 
written to the RAM 34. 

Immediate transfer ports can be used in various combi- 
nations with the bus master interfaces 148. 150 and other 
20 integrated peripherals and peripheral interfaces 174-183 
that access the FIFO pool 172. For example, the outbound 
data stream through the MIDI interface peripheral 174 may 
be transferred to a FIFO in the FIFO pool 172 by the host 
processor 12. When the change in the FIFO status in 



frame buffer into a wide buffer register, also configurable as 25 broadcast over the update bus. the MIDI interface peripheral 



an internal FIFO relative to the FIFO pool bus 144. Double 
word wide sections of the frame words can then be trans- 
ferred to and through the FIFO pool 172, 

The immediate transfer port integrated peripheral 182 is 
provided to establish high-speed, low latency connections 
through the FIFO pool 172 for typically low-bandwidth, 
latency sensitive data streams. The immediate transfer port 
integrated peripheral 182 provides preferably six indepen- 
dent transfer ports. Each transfer port is represented by a 
control register and a data register accessible via the HO bus 
146. The control register definition is provided in Table XL 



30 



33 



TABLE XI 


turned. Transfer Port CtL 


Description* 


Bit 


Space/Data Available 


set if space/data is available 


15 


Enable 


transfer port enabled flag 


14 


Reset 


react transfer port 


13 


Data Width 


8 01 16 data transfer 


9 


Direction 


transfer relative to FIFO 


8 


Interrupt Select 


00 => do interrupt generated 


[7:61 




01 => interrupt host CPU 






10 => interrupt DSP 1 






11 interrupt DSP 2 




FIFO Number 


number of the pool FIFO 


[4:0) 


Tmrnari. Trass for Poet Data 




Bit 


HifhByte 


upper byte of ward dWa 


115:8] 


Low Byte 


lower or only byte of data 


[7:0| 



174 places a request for access to the FIFO pool 172 with the 
FIFO pool arbiter. As soon as access is granted, data from 
the FIFO pool 172 is transferred to the internal FIFO of the 
MIDI interface peripheral 174 and promptly output. 

When data is removed from the identified FIFO In the 
FIFO pool 172. another immediate transfer port that has 
been programmed to respond to updates to the same iden- 
tified FIFO preferably does not generate a host interrupt. In 
this instances the host processor 12 determines the timing 
for writes of MIDI data to the identified FIFO. When the 
host processor 12 determines to write MIDI data, the new 
data is written into the identified FIFO by staging the data 
through the data register of the host associated immediate 
transfer port Where data is to be output at the maximum 
40 MIDI data rate, the host processor 12 can write more than a 
single byte or word of data into the FIFO of the FIFO pool. 
Thereafter, the host processor 12 can resume the output of 
MIDI data based on the time schedule determined by the 
host processor. Consequently, a low and substantially fixed 
45 latency cycle of transferring data from main memory 14 to 
the MIDI interface peripheral 174 can be sustained. 

Inbound data through the MIDI interface peripheral 174 
needs to be stored in system main memory 14 or RAM 34 
with time stamp data. This time stamp data needs to be 
50 applied to the inbound data with a minimum and regular 
latency from the actual time of receipt by the MIDI interface 
peripheral 174. Consequently, an inimediate transfer port is 
preferably associated with the MIDI input data FIFO in the 
FIFO pool 172 and programmed to issue an interrupt to 
either the host 12 or DSP 32 as data becomes available 
within the identified FIFO. 

A DSP accelerator integrated peripheral 183 can also be 
provided as part of the I/O channel controller 140. In general 
form, the DSP accelerator 183 preferably implements a 



53 



The control register for an immediate transfer port permits 
the port to be programmed with a FIFO identifier, an 
interrupt target, a data transfer direction, the data byte or 
word width, a reset bit. an enable bit, and a space or data 
available bit. 

The typical operation of an immediate, transfer port is to 
monitor the update bus portion of the PIO bus 146 for any 60 register interface available via the PIO bus 146 that supports 
status change of an identified FIFO and to inunedlately issue connection with one or more input FIFOs from the FIFO 
an interrupt to the host processor 12 or DSP 32. 36 based on pool 172 and one or more output FIFOs to return data to the 
the prograinmed interrupt selection bits. A data stream FIFO pool 172 via the FIFO pool bus 144. Internally, the 
transfer path is constructed between two processors utilizing DSP accelerator 1S3 may implement dedicated hardware, a 
2 immediate transfer ports and a single FIFO in the FIFO 65 rnicrocontroller. or both configured to perform, subject to 
pool 172. One of the unraediate transfer ports is preferably programmable control register configuration, any of a num- 
programmed to issue a host interrupt whenever space is ber of computationally intensive data processing operations 
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such as digital signal filtering, mixing and modulation. The 
number of FIFOs of the FIFO pool 172 connectable to the 
DSP accelerator 183 is therefore dependant on Che particular 
functions potentially implementable by the DSP accelerator 
183. 

The message port integrated peripheral 184 provides a 
simple data path for transferring small quantities of data 
between the host and DSP processors connected to the I/O 
channel controller 140. In the preferred embodiment of the 
present invention, three message ports, each dedicated to 
source use by a particular host processor 12 or DSP 32, 36, 
are provided within the message port integrated peripheral 
184. Each of the source dedicated message posts are repre- 
sented as two 16 bit registers accessible from the FIO bus 
146. Table XII describes the message port set and the control 
and data registers of each message port 

Table xn 



Message Port 


Description 




Port 0 
Port 1 
Pert 2 


host message send port 
DSP 1 message send port 
DSP 2 message send port 




Message Port CcatroJ 
Register for Port # 


Descriptions 


Bit 


Reset 

Interrupt Select 
Access Pointer 


reset transfer port 

00 => no interrupt generated 

01 => interrupt host CPU 

10 =*> interrupt DSP 1 

11 => interrupt DSP 2 

word onset pointer in message 


IS 
[14:131 

[7:0] 


Message Part Data 
Register for Port # 


DcGcriptaoos 


Bit 


Data 


read/write data register 


[15:0] 



The access pointer field operates as an auto increment 
pointer into a eight word (8x1 6-bit) deep message FIFO 
maintained internal to the message port To send a message, 
the source processor clears the access pointer field, writes up 
to eight data words to the data register of the message port 
and then programs an interrupt to specify the destination 
processor for the message. The interrupt is effectively issued 
on setting the interrupt select field to a non-zero state. 

To read a message in response to a message interrupc the 
destination processor may read the appropriate access 
pointer field to identify the message length, set the access 
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TABLE Xm 



Inner Source Registei 


r D'fiscrjp&oos 


Bit 


i nner Reset 
Count Value 
Count Down 


reset all Mrp^ B * 

sets base frequency of source elk. 
count down register 


31 
[30:16] 
[15:0| 


Timer 0 Register 


Descriptions 


Bit 


Enable 
Mode 

Clear Interrupt 
Interrupt Select 

Timer Value 


toner enabfe 

multisnotf single shot mode 
clear interrupt timer state 

00 no interrupt generated 

01 => interrupt boat CPU 

10 =o interrupt DSP 1 

1 1 => interrupt DSP 2 
timer count (town vahie 


31 
19 
18 
[17:161 

[1*01 


Host Latency Tuner 


Descriptions 


Bit 


Tuner Value 


timer count down value 


(1*01 



20 

The first of these control registers provides for a 15- bit 
free running counter that serves a prograinrnable time base 
for the other timer functions. The timer source register 
preferably includes a 15-bit down count field that ticks with 
25 each cycle of the system clock applied to the I/O controller 
140. A 15-bit count value field stores a static base clock 
count value that is used to re-initialize the count-down 
sub-field each time the count-down sub-field reaches a value 
of zero. A single bit is provided as a reset control for the 
30 entire timers peripheral 186. 

A general purpose timer zero register is provided to 
generate an interrupt on each expiration of the 16 bit 
count-down timer driven from the timer base clock. A timer 
zero register includes a 16 bit tinier value that is decre- 
35 mented with each complete cycle of the timer base clock. A 
two-bit sub-field is provided to specify the processor to be 
interrupted on expiration of the timer zero value. Interrupt 
dear and tuner enable bits are also provided. Finally, a mode 
control bit is provided to specify whether the timer zero is 
40 to act as a multi-shot timer or as a single shot timer. In the 
multi-shot mode, an expiration of the timer value an inter- 
rupt is generated and the timer value is reloaded. A second 
interrupt will only be issued only after a prior interrupt has 
been cleared. In single shot mode, the timer simply stops 
45 once an interrupt has been generated 

A specialized host interrupt latency timer is also imple- 
mented. This timer is a count-up timer driven from the timer 
base clock. A 16-bit timer value increments from zero 
beginning with the assertion of an interrupt to the host 



pointer field to zero to read the message from the beginning 

and then read the access pointer specified number of data jq processor 12. The host interrupt latency timer is stopped and 

A ' the timer value is cleared when the timer value sub-field of 
the host mterrupt latency timer register is read. This spe- 
cialized timer permits the VO controller core 140 to support 
analysis typically by the host processor 12 of me effective 



words from the data register of the message port. Once the 
message data has been read, the interrupt select sub-field can 
be simply reset to zero. Alternately, the sub-field can be reset 
to a value specifying the message source processor with a 



zero length message has to act as an acknowledge of the 55 rxrformance of the host interrupt service routine in respond- 



receipt of a message. An acknowledge or return message can 
also be written to the message FIFO before setting the 
mterrupt select sub-field to specify the source processor. In 
ail events, the destination processor can uniquely identify 
the source processor by recognition of the particular mes- 
sage port utilized to send a message, since each message port 
is uniquely associated with a source processor. 

A timer integrated peripheral 186 is provided to support 
both general purpose and special function time based opera- 
tions. In a preferred embodiment of the present invention, 
three double word registers arc presented by the timers 
peripheral 186 to the PIO bus 146. as detailed in Table XHL 



60 



65 



ing to interrupts generated by the I/O channel controller 140. 

Finally, an interrupt controller integrated peripheral 188 is 
provided to support management of the many different 
sources of interrupts generated by the I/O channel controller 
140 during typical operation. In order to efficiently use the 
interrupt inputs available on the host and DSP processors, 
the VO controller 140 preferably issues a single vectored 
interrupt to each of the processors. As shown in FIG. 5J, an 
interrupt register 242 generates, in the preferred 
embodiment a host interrupt on line 156\ a first DSP 
interrupt on line 164' and a second DSP interrupt on line 
165*. The inputs 244 to the interrupt register 246 are received 



02/12/2004, EAST Version: 1.4.1 



5,784,649 



29 



30 



from either individual interrupt sources within the I/O 
controller 140 ox from group interrupt registers 246. 250. 
The group interrupts can be read from the interrupt register 
242 via the PIO bus. Table XIV provides the preferred 
definition of the group interrupts. 

TABLE XIV 



Group interrupt Register 


Descriptions 


Bit 


Timer Mask 


enable interrupt source 


12 


tmn-i XFer Port Mask 


enable interrupt source 


11 


Message Mask 


enable interrupt source 


10 


Peripheral M*s* 


enable interrupt source 


9 


BTU Mask 


enable interrupt source 


8 


Timer Interrupt 


group interrupt active bit 


4 


ImiD. XFer Port Interrupt 


group interrupt active bit 


3 


Message Port Interrupt 


group interrupt active bit 


2 


Peripheral Interrupt 


group interrupt active bit 


1 


BTU Interrupt 


group interrupt active bit 


0 



Preferably, the interrupt register 242 permits each of the 
group interrupts to be masked. Where an interrupt group is 
enabled by application of the interrupt mask to generator an 
interrupt the selection of a specific interrupt target 156*, 
164', 165'. is determined by the interrupt target information 
provided with the group interrupt signals 244. Consequently, 
the individual interrupt source is determinative of the par- 
ticular interrupt destination though the interrupts are 
grouped through the interrupt register 242. 

Where a large number of interrupts may be generated by 
a single component of the I/O controller 140, such as the bus 
transfer control system 170, or where many related compo- 
nents can be conveniently grouped together, the interrupt 
request lines 248, 252 can be directed to second level group 
registers 246. 250. In a preferred embodiment of the present 
invention, a number of the integrated peripheral and periph- 
eral interfaces 174-186 are routed through a peripheral 
group interrupt register 246 to provide a single group 
interrupt to the interrupt register 242. Internal peripherals, 
such as the MIDI interface 174, and external peripherals 
such as those provided on the DSP bus 30 can each be a 
source of peripheral group interrupt Table XV provides a 
preferred definition of the group mask and interrupt state 
register accessible via the PIO bus 146. 

TABLE XV 



Group Interrupt Regis tea 


Descriptions 


Bit 


Interrupt? Mask 


enable interrupt source 7 


IS 


Interrupt 1 Mask 


enable interrupt source 1 


9 


MIDI Mask 


enable MIDI interrupt source 


8 


External Interrupt 7 


external interrupt 7 active bit 


7 


External Interrupt I 


external interrupt 1 active bit 


1 


MIDI Interrupt 


peripheral interrupt active bit 


0 



The group interrupt register 250 preferably provides a 
irnmediate port index field that reflects the interrupt state of 
each of the immediate transfer port interrupts. A single bit 
flag is used to mark whether the current readable index is 
valid or not. The irrimediate transfer port register (Table 
XVI) is accessible via the PIO bus 146. 



TABLE XVI 


TIP Interrupt Registe 


r Descriptions 


Bit 


m> Index Invalid 


valid/invalid flag; write to invalidate 


7 


nP Index 


index of TTP in IT? array 


[2*1 



Finally, a BTU group interrupt register 254 provides a 
control register (Table XVII) that includes a BTU index field 
10 for identifying a specific BTU that is the source of an 
interrupt signal 256. 

TABLE XVH 



15 BTU Interrupt Register Descriptions 



20 



Bit 



BTU Index Invalkl valid/invalid flag; write to invalidate 7 
Transfer Done BTU transfer is complete 6 

BTU Index index of BTU in BTU table 150] 



A separate transfer done bit is provided to signal whether the 
interrupt is signalling the completion of a data stream 
transfer. Finally, a single control bit is provided to specify 
whether the BTU index field is valid when read. 
The interrupt controller integrated peripheral 188 thus 
23 provides a concise register system 240 for interrupting any 
of a number of different processors quickly in response to 
any of a large number of individual internal interrupts. 
Whenever a processor is interrupted, at most two register 
read operations via the PIO bus 146 are required to uniquely 
30 identify the interrupting source. 

VL Multi-Threaded Elastic Buffer FIFO Pool 

A detail view 260 of the FIFO pool 172 and the control 
relationship between the FIFO pool 172 and a number of 
FIFO access requesting devices 26 V~262„ is shown in FIG. 
35 6. The FIFO access requesting devices 262o-262„. prefer- 
ably include the bus master interfaces 148, 150 and the 
integrated peripherals and peripheral interfaces 174-183. 
Each of the devices 262o* continually monitors the FIFO 
update bus 173 for a change in the status of any of the FIFOs 
40 assigned to a particular device 262^. In particular, each 
device 262^ monitors the update bus for the number of the 
FIFO being updated and acterrnines whether sufficient space 
or data is available in the updated FIFO to support a data 
transfer between the device 262^ and the FIFO pool 
45 memory 284 via the FIFO pool bus 144. 

In response to the broadcast of a qualifying status change 
in a FIFO assigned to a particular device 262^, the device 
26 2o^ provides an access request control signal to a FIFO 
arbiter 264 via the FIFO pool bus 144. During each arbi- 
50 tration cycle, the FIFO arbiter 264 efficiently considers only 
those devices 262o-» that are requesting access to the FIFO 
pool 284 as uniquely represented by the set of then pending 
request control signals. The next device in the current 
arbitration cycle of the FIFO arbiter 264 is selected to have 
55 access to the FIFO pool 284. A unique acknowledge signal 
is returned by the FIFO arbiter 264 to the selected device 
262o. N * In response, the device 262^ provides control 
signals including at least the FIFO identifier maintained by 
the device 262ov» through the FIFO pool bus 144 to selector 
60 a data storage line within a FIFO flag store 286 and a FIFO 
control stores including a FIFO read/write pointer storage 
array 272; 274. 

The flag store and pointer arrays 286, 272, 274 are 
preferably implemented as RAM register arrays having a 
65 depth equal in number to the number of FIFOs supported by 
the FIFO pool 284. In the preferred emrx)diment of the 
present invention, the FIFO pool provides storage for 24 
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16-byte deep FIFOs. Table XVm lists the flag bit definitions 
for each line of the FIFO flag store 286. 

TABLE XVm 



FIFO Flags 


Description 


Bit 


Transfer Done 


flag that transfer is complete 


12 


BTU Done 


flag that current BTU is done 


11 


FIFO Size 


FIFO size is greater than 16 bytes 


10 


Read Size 


number of data bytes in FIFO 


19:41 


Read Byte Enables 


read byte selection within FIFO 


13:21 


Write Byte Enable* 


write byte selection within FIFO 


|1:0) 



The FIFO number provided on lines 276 from the FIFO 
pool bus 144 is used as an address to select a unique array 
line in the FIFO flag store 286 for use in updating the control 
data stored in the selected array line. The FIFO number is 
further used to select a corresponding array line in the FIFO 



read and write pointers, the active byte enables and other 
control information* such as data transfer direction, through 
the FIFO pool bus 144 to the FIFO pointer logic unit 266. 
The data transfer direction control signal determines 
whether the FIFO read or write pointer array value is 
provided to the I/O multiplexer 282. The byte enables define 
the width and alignment of the data transfer performed 
between the FIFO pool 284 and FIFO pool bus 144. thereby 
allowing independence between the data stream transfer 
widths of any of the devices 262^ that are mutually 
accessing a common FIFO within the FIFO pool 284. 

On completion of each read or write cycle through the I/O 
multiplexer 282. as determined by the selected device 262o-» 
15 via the FIFO pool bus 144. the FIFO pointer logic unit 266 
updates the appropriate read or write pointer array value in 
the FIFO control store 272. 274. The FIFO pointer logic unit 
266 also updates the corresponding line of FIFO flags in the 
FIFO flag store 286. In particular, the FIFO pointer logic 



10 



read and write pointer airays 272. 274 to enable the use of 
either a read or write pointer for the identified FIFO. Finally. 

the FIFO number on lines 276 is provided to an I/O 20 UD it 266 updates the number of bytes of data remaining in 



multiplexer 282 to enable data transfer between the identi- 
fied FIFO in the FIFO pool memory 284 and the FIFO pool 
bus 144. 

The field definitions for the combined read and write 
pointer arrays 272, 274 are provided in Table XTX. 

TABLE XIX 



25 



FIFO R/W Pointers 


Description 


Bitfs 


Read Pointer 


Current FIFO read location 


[15:9] 


Write Pointer 


Current FIFO write location 


[8:2] 


FIFO Size 


Allocated sue of FIFO 


11:0] 



the accessed FIFO and the qualitative flags, such as transfer 
done and BTU done. 

Once one or more bytes of data have been transferred, 
depending on the number of bytes immediately available to 
be received by or received from an internal FIFO of the 
selected device 262^, and the number of bytes available in 
the corresponding FIFO of the FIFO pool 284. the FIFO 
access request is withdrawn by the selected device 262o_ B . A 
30 new arbitration cycle then begins and the FIFO pool arbiter 
264 generally selects the next device 262^ for access to the 
FIFO pool 284. 

The devices 262o-n propagate a transfer done signal 
through the FIFO pool bu s 144 to the FIFO pointer logic unit 



The size field defines the length of the FIFO. In the preferred ^ m 

embc<liment of the present invention, a FIFO size value of 35 266 to signal the terniination that is sourced by or received 
"(XT denotes a 16 byte FIFO depth. The value "01* specifies 
a 32 byte FIFO depth and a value of 4< 1(T specifies a 64 byte 
FIFO depth. The read and write pointers function to p rovide 
six bit FIFO byte offsets into the currently selected FIFO. 



by any of the device 262^. The bus master devices 148. 150 
also propagate a BTU done signal whenever the current 
BTU is complete. In both instances, the FIFO pointer logic 
unit 266 handles the potentially partial FIFO data transfer 



The high bit in ^^ Md ^.P°^' t fP w S y ^ 40 that may currently remain in thVcorresponding internal 

Kf*u k;+ fx* 1 £ hut* tJTCOc ciYth hit tVir "M Hvtp FTPOb and ' 7 ~ ^ 



fifth bit for 16 byte FIFOs, sixth bit for 32 byte FIFOs and 
seventh bit for 64 byte FIFOs, is used to indicate whether a 
FIFO wrap-around condition exists while indexing through 
the FIFO 



FIFO of a participating device 262^ or corresponding FIFO 
of the FIFO pool 284. 
Typically, host processor 12 based initialisation and sub- 



In order to simplify allocation and management of FIFOs 45 sequent status checking of FIFO flag store 286 and the FIFO 



within the FIFO pool 284. each array line in the FIFO flag 
store 286 and read and write pointer arrays 272. 274 
correspond to defined FIFO RAM blocks within the FIFO 
pool 284. Preferably, each FIFO RAM block is a 16 byte 
boundary aligned sequence of 16 bytes of FIFO RAM 50 
located within the FIFO pool 284. Consequently, the maxi- 
mum mutual depth of the FIFO flag store 286 and read and 
write pointer arrays 272, 274 define the maximum number 
of concurrently supportable FIFOs within the FIFO pool 
284. Where 32 or 64 byte long FIFOs are defined by the size 55 
field of the read and write pointer arrays 272, 274. two and 
four contiguous FIFO RAM blocks are utilized within the 
FIFO pool 284. The specification of each 32 byte FIFO or 64 
byte FIFO thus necessarily preempts the Independent use of 
one or three additional array lines. 60 

A FIFO pointer logic unit 266 and the FIFO control store, 
including the read and write pointer arrays 272. 274, operate 
together to implement a state machine that is enabled by the 
FIFO arbiter 164 via an enable signal on line 268 upon 
selection of a device 262^ to participate in an access of the 65 
FIFO pool 284. The selected device 262^ provides its FIFO 
number on the lines 276 to select the corresponding FIFO 



control store 272, 274 can be performed effectively through 
the FIFO pointer logic unit 266 subject to coordiriation with 
the FIFO pool arbiter 264. A set of programmable registers 
are preferably presented to the FIO bus 146 via control. 
FIFO index and data lines 290 that allows the current FIFO 
flags associated with a pool FIFO to be read by or written 
from the PIO bus 146. 

The register presentation of the FIFO Flag array by way 
of the FIFO pointer logic unit is provided in Table XX. 



TABLE XX 


FIFO Flags 


Deaciiptjon 


Bh/e 


FIFO Flags 0 


FIFO Flags for FIFO 0 


16 


FIFO Flags 1 


FIFO Flags for FIFO 1 


16 


FIFO Flags 23 


FIFO Flags for FIFO 23 


16 



The register presentation of the FIFO control store 272, 
274 effectively by way of the FIFO pointer logic unit 266 is 
provided in Table XXL 
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TABLE XXI 




FIFO Pointers 


Description 


Bh/s 


FIFO Control Regs 0 


FIFO R/W Pm for FIFO 0 


16 


FIFO Control Regs 1 


FIFO R/W Ptrs for FIFO 1 


16 


FIFO Control Regs 23 


FIFO R/W Ptrs for FIFO 23 


16 
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priority, followed by the host and DSP bus master interfaces, 
and finally the BTU scanner. The BTU scanner, in turn, 
ensures that all BTUs have generally fair access to the BTU 
table 192. By operation of the PIO controller 151. (he host 
and DSP bus slave units 158. 166 present a shared access 
request and receive a shared enable response from the BTU 
arbiter 190 via control lines in the PIO bus 146. The PIO 
controller determines the bus interface module 148. 150 that 



Although both the host processor 12 and digital signal 10 is enabled to respond to the enable response from the BTU 
processors 32, 36 may read and write the FIFO flag and arbiter 190. When an enable PIO signal is provided via the 
control stores 286, 272, 274, initialization, including ere- control lines 292 to the host or DSP bus slave 158, 166. a 
ation and destruction of defined FIFOs within the FIFO pool BTU index value is passed via the PIO bus 146 and address 
284 is preferably managed exclusively by the host processor lines 294 to an address multiplexer 296. Simultaneously, the 

12. By denning the host processor 12 as the exclusive 15 BTU arbiter 190 provides a selection signal via control line 
allocation manager for FIFOs within the FIFO pool 284, 298 to select the PIO provided index as an address selecting 
interlocks between the host and DSP accesses to the FIFO an entry in the BTU table 192. The host or DSP bus slave 
flag store 286 and FIFO the FIFO read and write pointer 158, 166 can then read or write the corresponding BTU 
arrays 272. 274 are not required. Instead, the message port within the BTU table 192. 

184 rrmy be utilized to r^ass short messages between me host 20 

processor 12 and UDSPs 32, 3* to request and acknowledge ^ te acccss te t0 Ac BXU 

the creation and FIFO identifier of any particular FIFO that . ? * . 45 " , ■ 4 ^* , * * 

ht^n newly created within the FIFOpool 284 as effec- arbiter 190whenever the interfaces are ^se idle. T*e 
lively requested by either the host processor 12 or DSPs 3Z <* a ^ <*? SP access «2«* bv * e BTU arbiter 190 

36 25 * s conditioned additionally on the identification of an avail- 

An additional feature presented by the rxogrammabiUty of able or enabled BTU defined transfer for either bus master 
the read and write pointer arrays 272, 274 is that FIFOs interface 160. 168 as determined by the BTU scanner 196. 
within the FIFO pool 284 can be dynamically sued as The control lines 171 connecting the BTU scanner 196 with 
needed to ensure that data overruns and undemins are the FIFO flag array 270 provide an array index to the flag 

avoided. Both 64-byte and 32-byte FIFOs within the FIFO 30 array 270 and provide for the return of at least a subset of the 
pool 284 can be shrunk in increments down to a minimum FIFO flags stored in the corresponding array line. Preferably. 
16-byte length simply by reprogramming the size field the FIFO flag array 270 is implemented as dual ported 
maintained FIFO control store 272. 274. Consequently, new memory thereby allowing the BTU scanner 196 to continu- 
16-byte and potentially 32-byte FIFOs may then be allocated ous i y and largely independently scan the FIFO flag array 

within the FIFO pool 284 within the FIFO memory block or 35 270 while accesses by the devices 262^ proceed. The dual 
blocks no longer used by a shrunken FIFO. Conversely, memory implementation of the FIFO flag array 270 

FIFO lengths can be dynamically grown from 16 to 64 bytes provides for m appropriate access interlock that temporarily 
subject to the constraints that the base FIFO RAM block is staUs mc BXU 196 whcncV er the scanner attempts 

properly aligned within the FIFO pool 284, the adjacent t0 rcad a flag anay line that is in the proces s of being updated 

FTFO RAM blocks are not aheady in use. and preferably the 40 ^ m u ^ scanncr stalls are 

FIFO is empty to simplify FIFO management , . . 

VTL Bus Transfer Unit Scan Control Logic infrequent and brief. 

A detailed view of the bus transfer control system 170 is The BTU scanner 196 operates to perform a qualified 
shown in FIG. 7. The bus transfer control system 170 sequential scan of the BTU table 192 to identify a next 

operates to manage three substantially independent high 45 potential BTU to be programmed for the PCI bus master 
priority processes mat each require access to the BTU table interface 160 or DSP bus master interface 168. The sequen- 
192. The BTU arbiter 190 serves as the primary controller tial scan of the BTU scanner 196 is qualified by the state of 
for receiving access requests and selecting one of the three the enable bit in each of the BTU entries within the BTU 
processes for a BTU table access. These three processes table 192. The state of these enable bits may be directly read 

include a PCI interface transaction process, a DSP interface so by the BTU scanner 196 via control lines 300. The operation 
transaction process, and a bus slave transaction process. 0 f me jjttj scanner 196 can therefore be efficiently limited 

The PQ interface 160 generates both access and update t0 sequentially scanning only enabled BTUs. Thus, newly 
request to the BTU arbiter 190. An access request indicates CTCate d and established BTUs within the BTU table 192 are 
that the Pa interface 160 is available for programming to Uar^^y included within the BTU scan while BTUs that 

perform a host bus rnasterdata^sfer operation. An update 55 m d^ied for whatever reason are immediately excluded 
access is requested by the KZmteficc 160 to update a ^ mthescaiL the BTU scanner 196 selects the next 
c^es^ndmgBTO within the BTU table 192 uponccm^e- to examine , mc BTU address is provided to 

*°*J* \ ^JT^ %f * * toe multiplexer 296 via BTU address lines 302. The default 

interface 168 issues both access and update requests to the *~/T . . , . ™- r _ 

BTU arbiter 190 to request programiningfr oma BTU in the 60 S ^°**'™^ pl ™?» ™Z ^ 
BTU table 192 and subsequently update the BTU on provided addresses the default enabled address provided to 
completion of the DSP bus master data transfer. Finally, each * c *™ 19Z At lcast a P 01 * 011 of the BTU is read 
of the bus slave units 158. 166 may request access to the &om me BTU table 192 and stored in either of the scan 
BTU table 192 to program a new BTU or to examine the registers 304, 306. The scan registers contents are presented 

contents of a current BTU. 65 to the BTU scanner 196 via control lines 308, 310. The BTU 
The BTU arbiter 190 implements a fixed priority selection information, a stored by the scan registers 304, 306. is 
mechanism with PIO bus requests having the highest specified in Table XXII. 
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TABLE XXH 


Scan Register 


Description 


Bit/s 


FIFO Deadlock 


dtadkxk/incgulai transfer length 


12 5 


BTU Done 


best BTU done after current burst 


11 


Interrupt Enable 


force interrupt on current BTU done 


10 


BTU busy 


scan BTU is currently in use 


9 


Override 


move scan BTU to best BTU reg 


8 


Mitid for Programming 


best BTU can be used for Bus Master 


7 


prograxxuning; set when scanner 


10 




passes lite BTU index value 




Valid 


best BTU has valid BTU index 


6 


BTU Index 


index of BTU in scan register 


[5:01 



The BTU irjformation. as stored In the best BTU registers l5 
312, 314. is specified in Table XXm. 



TABLE XXm 



Best Register 


Description 


Bit/s 


FIFO Byte Enables 


byte selector wilhm FIFO 


113:14] 


Buret Length 


number of bytes to transfer 


[13:8] 


Transfer Done 


stream is done alter best BTU burst 


7 


Link 


program for BTU link, not transfer 


6 


BTU Index 


index of BTU in best register 


[5:0] 
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The BTU information, as stored in the current BTU 
registers 320, 322, is specified in Table XXIV. 



TABLE XXIV 


Current Register 


Description 


Bit/s 


Interrupt Select 


00 => no interrupt generated 


[15:141 




01 => interrupt host CPU 






10 => interrupt DSP 1 






11 => interrupt DSP 2 




Buret Length 


number of bytes to transfer 


U3:S] 


Transfer Done 


stream is done after current burst 


7 


Link 


program BTU link, not transfer 


6 


BTU Index 


index of BTU in best register 


[5:0] 
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The BTU control register is specified in Table XXV. 



TABLE XXV 


Best Register 


Description 


Bit/s 


Reset 


reset entire BTU subsystem 


9 


Pulse Enable 


single step the BTU scanner 


8 


Reserved 




[7:2] 


Always V4P 


BTUs always valid for programing 


1 


Enable 


enable operation of BTU scanner 


0 



45 
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Based on die information provided from the scan registers 
304, 306, the BTU scanner 196 determines the particular 
interface 160, 168 and FIFO referenced by the BTU. The 
FIFO index is men applied via control lines 171 to obtain 
corresponding FIFO flag data from the FIFO flag array 270. 55 
Specifically, the FIFO flag data considered by the BTU 
scanner 196 includes whether the referenced FIFO can 
accommodate or presently stores sufficient data to support a 
bus master burst transfer. In the preferred embodiments of 
the present invention, each burst transfer has a maximum 60 
length of 16 bytes. However, one of the FIFO flags consid- 
ered by the BTU scanner 196 is the transfer done flag that 
allows the BTU scanner 196 to appropriately consider 
enabling a burst transfer of less than 16 bytes. Also, the 
deadlock flag, when set is used to force a partial data 65 
transfer rather than wait optimally for a full burst to be 
available. A deadlock may arise where only a partial burst is 
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transferred due to an irregular data length transfer or pos- 
sibly an error condition. The optimal transfer length of data 
for the participating devices is not available in the FIFO and 
an optimal length of data cannot be transferred to the FIFO. 
In any event, the device leaving a FIFO in a deadlock state 
will set the deadlock flag to force a short data transfer by the 
next device to access the FIFO. 

Where the BTU scanner 196 determines that a burst data 
transfer can be performed through the applicable bus master 
interface 160. 168. a determination is then made as to 
whether the identified BTU has sufficient priority to be 
staged to either of the best BTU registers 312, 314. subject 
to when the BTU comes ready. BTU priority for staging is 
generally based on the relative least recent use of the BTU 
in performance of a burst data transfer. Where the BTU 
identified by the scan register 304. for example, has a higher 
priority than the BTU identified by the best BTU register 
312. or if the best BTU register 312 is empty, the contents 
of the scan register 34 is copied down to the best BTU 
register 312 under the control of the BTU scanner 196 by 
provision of appropriate control signals via control lines 
316. Conversely, if the staging priority of the BTU identified 
by the scan register 306 is less than that of the BTU 
identified by the best BTU register 314. the BTU scanner 
196 does not provide for a copy down of the contents of the 
scan register 306 to the best BTU register 314. In either 
event the BTU scanner 196 has completed a current scan 
cycle and proceeds to select the next qualified BTU from the 
BTU table 192 for potential staging toward use in control- 
ling a bus master burst data transfer. 

The BTU scanner 196 interoperates with the BTU arbiter 
190 to signal whether either or both of the best BTU 
registers 312. 314 identify a respective BTU available for 
use in performing a burst data transfer. Based on this 
information, the BTU arbiter 190 can determine whether to 
provide an enable PCI or enable DSP signal to one of the 
interfaces 160, 168 in response to an access request. The 
BTU arbiter 190 signals the BTU scanner 196 when either 
of the enable PCI or enable DSP signals is issued by the 
BTU arbiter 190. The BTU scanner 196 thus may enable a 
bit parallel transfer of the contents of the corresponding best 
BTU registers 312. 314 to the corresponding current BTU 
register 320, 322. Concurrently, the BTU scanner 196 
updates an internal BTU priority bit list that is subsequently 
utilized in distinguishing the relative priorities of BTUs 
identified in the scan and best BTU registers 3#4, 306. 312, 
314. 

The contents of an enabled best BTU register 312. 314 are 
provided to the corresponding PCI or DSP interface 160. 
168. Concurrently, a BTU identifier is provided via address 
lines 324 to the nniMplexer 296 for use in selecting the best 
BTU register identified BTU from the BTU table 192. With 
the issuance of the enable control signal by the BTU arbiter, 
a current BTU address select signal is provided via the 
control lines 298 to the multiplexer 296. The complete BTU 
is thus addressed and made available for use in program- 
ming the PCI or DSP interface 160. 168 for the performance 
of a burst mode data transfer. Once programmed, the PCI 
and DSP interfaces 160, 168 participate as any of the devices 
262^ in requesting access to the FIFO pool 284 subject to 
the designated direction of the burst data transfer Where data 
is to be transferred to a FIFO within the FIFO pool 284. the 
burst data transfer is performed prior to the device 160. 168 
requesting arbitrated access to the FIFO pool 284. Where the 
data transfer is from the FIFO pool 284, the devices 160, 168 
first arbitrate to obtain data from the FIFO before perform- 
ing the burst data transfer. Both the PCI and DSP interfaces 
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maintain internal burst data FIFOs providing sufficient stor- DSP interfaces 160. 168 to load a next sequential BTU into 

age to buffer a single data burst each. In a preferred the BTU table 192 to maintain continuity of the data stream 

embodiment of the present invention, the PCI internal burst to the CODEC interface 176. Since the stream data may be 

data FIFO is 32 bytes in depth while the DSP internal FIFO stored as fragments in either the system main memory 14 or 

is 16 bytes. 5 DSP RAM 34, chained sequences of BTUs that respectively 

Once the PO ox DSP interface 160. 168 has completed a identify the data fragments serves to efficiently implement a 

bus master data transfer relative to the FIFO pool 284. the scatter/gather mechanism, Since the processing of the BTUs 

interface 160. 168 requests a PCI or DSP update. The update for transfer of the stream data as well as reloading chained 

request to the BTU arbiter 190 is not qualified by the or linked-to-BTUs is performed autonomously with respect 

selection of a new BTU. Rather, the BTU identified by the 10 to the host processor 12 and DSPs 32. 36, particularly in that 

contents of the current BTU registers 320. 322 are imme- no interrupts are necessarily generated that require servicing 

diately utilized. Consequently, the update operation is by the host processor 12 or DSPs 32, 36. the effective use of 

applied to the BTU utilized to program the immediately the host processor 12 and DSPs 32. 36 is maintained 

preceding burst data transfer. With the issuance of either the essentially independent of the ongoing operation of the I/O 

enable PO or enable DSP signals by the BTU arbiter 190, 15 channel controller 22 Preferably, the last BTU in the 

the PO or DSP interfaces 160, 168 are enabled to write back chained sequence of BTUs controlling the transfer of the 

updated information into the BTU identified by the contents data stream to FIFO 1 is programmed to initiate an interrupt 

of the corresponding current BTU register 320. 322. With on completion of the BTU specified data transfer, 

this update, the status of the transfer done flag is effectively Data received from the CODEC interface 176 is demand 

transferred to the referenced BTU. The equivalent flag in the 20 driven into the FIFO 2 for transfer, for example, to system 

FIFO flag store is also updated, though preferably in con- main memory 14. As data is received by the CODEC 

nection with the burst transfer itself. Once the BTU update interface 176, the interface requests access to the FIFO pool 

has completed, the corresponding PO or DSP interface 160, to transfer data at a data rate consistent with the receive data 

168 again asserts an access request to the BTU arbiter 190 rate of the CODEC interface 176. Again, as FIFO 2 fills 

and awaits BTU programming. 25 sufficiently to qualify for a bus master transfer, the BTU 2 

The PO and DSP interfaces 160, 168 may be pro- will be selected for the programming of the PCI interface 

grammed to generate interrupts in connection with the 160 to perform a burst data transfer of data from FIFO 2 to 

performance of a burst data transfer and potentially in system main memory 14. 

response to a data transfer error. The PO and DSP interfaces When the data stream to or from the CODEC interface 

160, 168 provide completion and error control signals to an 30 176 to FIFO 1 or FIFO 2 terminates, the corresponding FIFO 

interface interrupt controller 326. The burst completion flags will be updated to reflect a transfer done status. This 

response interrupt operation of the PO and DSP interfaces status will be reflected into the last chained successor BTU 

160. 168, as programmed into and provided from the BTU to BTU 1 or BTU 2 Ultimately, the transfer done will cause 

table 192 is stored in the current registers 320. 322 when the a FIFO reset operation to clear the FIFO. Consequently, an 

best registers 312. 314 are copied down to the current 35 interrupt can be generated upon the final transfer of data to 

registers 320, 322. The programmed interrupt response FIFO 1 or from FIFO 2. 

behavior is appropriately provided from either of the current FIG. Sb illustrates a more complex bi-directional data 

registers 320. 322 to the interface interrupt controller 326 stream transfer involving data from system main memory 14 

each time the PO or DSP interface is enabled to perform a being transferred through a FIFO 3 to a DSP 32 to a CODEC 

burst data transfer. On completion of the burst data transfer 40 interface 40 directly connected to the DSP 320. Since data 

or detection of an error condition, the interface interrupt transfers from system main memory 14 and to DSP RAM 34 

controller 326 provides interrupt defining control signals, if are bus master transfers, two separate BTUs 3 and 4 are 

any interrupt is to be generated, on the control lines 328 to utilized to control the transfer of data through FIFO 3. In this 

the main interrupt controller 18a example, BTU 4 is programmed into the BTU table 192 by 

VTJJ. Demand Driven Data Transfer Operations 45 the DSP 32 while the BTU 3 is programmed by the host 

A number of exemplary data and control path examples processor 12. Since the DSP 32 is responsible for managing 

are shown in FIGS, 8a through 8c. A logical bi-directional a data destination section of the RAM 34 pointed to by BTU 

interface to a CODEC interface 176 is established through 4. the DSP 32 may establish the BTU 4 and chained 

the use of two FIFOs and four BTUs. Since the FIFOs are successors to specify the transfer of corresponding blocks of 

independently uni -directional with respect to the transfer of so data of desired size and cause the generation of an interrupt 

data, a separate BTU is associated with each of the FIFOs to as the transfer of each or only the last block of data to the 

establish the management of data transfer paths. DSP RAM 34 is completed. Meanwhile, the BTU 3 and 

The CODEC interface 176 operates as a consumer of data chained successors become active in the operation of the bus 

from FIFO 1. A CODEC interface 176 therefore requests transfer control system 170 as adequate room in FIFO 3 

access to the FIFO pool 284 at the data transfer rate 55 becomes available for data burst transfer. Preferably, when 

established by the internal operation of the CODEC inter- the last data burst transfer to FIFO 3 is performed, the 

face 176. Meanwhile, the BTU 1 participates in the scanning chained successor BTU to BTU 3 will specify the generation 

operation of the BTU scanner 196. As data is drawn from of an interrupt to the host processor 12. Alternately, the host 

FIFO 1 by the CODEC interface 176. the FIFO flags are processor 12 may send a simple message through the 

updated until sufficient room exists within FIFO 1 for a burst 60 message port 184 to the DSP 32 to specify that the data 

data transfer. BTU 1 then becomes eligible for being stream transfer is complete on the final emptying of the 

selected by the BTU arbiter 190 to program either the PO FIFO 3. 

interface 160 or DSP interface 166 for a burst for a burst data Data received by the DSP 32 from the CODEC interface 

transfer from either system main memory 14 or DSP RAM 40 may be processed by the digital signal processor 32 and 

34 to FIFO 1 as specified by the programming of FIFO 1. 65 then stored in a buffer location within the RAM 34. Once a 

As the transfer size of BTU 1 is exhausted* a bus master block of data has been established in the DSP RAM 34. a 

data transfer may be performed through either the PO or BTU 5 may be programmed by the DSP 32 into the BTU 
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table 192. Shortly after being enabled, BTU 5 will be used Finally, data received and processed by the DSP 36 may 

to program burst data transfers from the DSP RAM 34 to be transferred through, for example, the CODEC interface 

FIFO 4. As FIFO 4 fills sufficiently to support a burst data 42 for further processing, or through a FIFO 7 to system 

transfer, a BTU 6 pre-established by the host processor 12 main memory 14 subject to the mutual control of BTUs 8 

will qualify for arbitration selection to program the PCX bus 5 and 9. or both. 

master interface 160 to perform a burst transfer of data to The processes described above in regard to FIGS. 8a-c. in 
system main memory 14 at the address specified by BTU 6 accordance with the present invention, may be and typically 
or a chained successor BTU. To terminate the data stream. are mutually independent of one another. Each of the pro- 
the DSP 32 could transfer a message through the message cesses can represent an independent data stream being 
port 184 to the host processor 12 specifying the total amount 1Q transferred subject to an independent control thread between 
of data that is to be transferred. A final BTU may then be the host processor 12 and the data sources and sinks as so- 
established by the host processor 12 reflecting the total dated with the I/O channel controller 22. The present 
expected amount of data remaining and to generate an invention, however, specifically enables these and poten- 
interrupt once that data has been transferred to system main other process to proceed concurrently. Furthermore, 
memory 14. Preferably, however, the DSP 32 instead directs due to ^ demand driven operation of each of the streams, 
the DSP bus master unit 150 to propagate a transfer done " me utilization 0 f the I/O channel controller 22 is fairly 
signal in connection with the transfer of the current and final ^ a dynamic and continuing basis to ensure that 
portion of me stream data. . _ . _ ___ the fundamental data transfer rate of each stream meets the 

Amore complex example is WHG. 8c. A MIDI peripheral data source or sink, 

interface 174 is connected through a FIFO 5 to receive data ™™ UJ mc 1 

from system main memory 14. The host processor 12 20 lA^iunmary 

preferably utilizes an mimediate transfer port 18^ to pro u **** a miction VO peripheral support system has 

vide data into the FIFO 5. Since the timmg^me^trxiund ^ ™ e SyS ^ V1 ^ 

MIDI data transfer stream is managed by the host processor tiaUy autonomously opeiaUng. ^^eaded data stream 

Uit^lf.memiir^tetransferpo^ Misused by the host J"?^ ~ V"*^ matched to me demanded I/O 

processor 12 to passively provide data i> the FIFO 5. The 25 baiHiwidth of the integrated and external ^pmpheral devices 

use is passive in mat no mterrupt is generated in response to connected to the peripheral system. In ad^on, the p*^ 

the placement of data into the FIFO 5. Rather, theMIDI CTal ■Y*» r^ovioes memory to memory dau transfer 

toerfETm is established to request a FIFO pool access "W* TfP le s ^ ^son that can be 

whoever data is present in me^rresponding FEFO 5. In Posing and interrupt intensive tasks 

general, the latent completing the data transfer from the 30 from ^ host pr^sor whdle, at the i*^S 

rWoStomeMlrimter^^ ^tF^JEti ^£J£f 

uniform in view of the normal data rates of a MIDI device. P'f* SOT in mar*^^^ 

ConsequenUy. unlike the demand driven operation of other * viw of the ^<*j^^ 

data fransfers managed through the VO channel controller men * <* * e ^ ^ Y J? 

i " 6- —Ain'/iiii ,« variations of the disclosed embodiments will be readily 

core 26 of the present invention, the rate of data provided 35 v<uia "J . . , tn -i 

lL , ^ **mr * m a :„ ^.1^ appreciated by those of skill in the art It is tnereiare to be 

* d IS*? unde^ood ft* within the scope of the appended claims. 

Date originating or inbound from the MIDI interface 174 * ***** *" SpedfiCaUy 

is provided directly to a FIFO 6 effectively at the receipt data , . Ve * 

rate established by the MIDI interface 174. As each byte or 40 We claim: 

^ J , . . - A . ^ - _ ' 1. A bus transfer control system for managing the transfer 

word of data is received through the interface 174, a request *' *™» " J * ^ A r~* . ie 

is immediately placed to transfer the data to a corresponding <* continuous asynchronous data streams, said bus 

FIFO in the FIFO pool 186. Again, in general the latency in transfer control system comprising: 

completing the data transfer to the FIFO 6 from the MIDI a) a buffer pool definable as a plurality of memory 

interface 174 is minimal and adequately uniform in view of 45 buffers, capable of storing a plurality of data stream 

the normal data rates of a MIDI device. segments representing one or more data streams; 

A second immediate transfer port 182, is preferably b) a plurality of data transfer devices coupled to said 

established to actively generate an interrupt to. in this buffer pool and to a plurality of memory spaces, said 

instance, a DSP 36 each time inbound MIDI data is placed data transfer devices supporting toe iterative transfer of 

in the FIFO 6. In response to the interrupt, the DSP 36 50 data stream segments between said memory buffers and 

retrieves the data from the FIFO 6 through the immediate said memory spaces, said data transfer devices provid- 

transfer port 182^ records a corresponding time stamp, and ing requests for data stream segment transfers in 

stores both in the DSP RAM 34. Consequently, the DSP 36 response to toe accessibility of said memory spaces to 

can efficiently receive, time stamp, and process data receive and provide data stream segments; and 

received from the MIDI interface 174 with a niinimurn, 55 c) a transfer controller, responsive to said requests and 

substantially fixed latency. Although the immediate transfer providing storage for status information as bus transfer 

port 182 ! will generate a significant number of DSP units that define respective data streams, said transfer 

interrupts, the read rate of MIDI data transfer is fairly low controller iterativeiy scanning said bus transfer units to 

and the DSP 36 is typically fairly efficient in servicing select a first bus transfer unit and enable the transfer of 

interrupts. In any event the entire processing overhead of 60 a first predetermined data stream segment between said 

these MIDI related interrupts is isolated to the DSP 36 and buffer pool and a first data transfer device specified by 

shielded from both the host processor 12 and any other DSP said first bus transfer unit in a predetermined scan 

32. The resultant data processing load on the DSP 36 can be iteration. 

selected so that any concurrent processing of data to be 2. The bus transfer control system of claim 1 wherein said 

provided to or received from a directly connected CODEC 65 first data transfer device obtains a first predetermined por- 

interface 42 relative to the DSP RAM 34 is within the data tion of said status information stored by said first bus 

processing capability of the DSP 36. transfer unit by obtaining r^ogramming from said transfer 
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controller, said first data transfer device updating said first 
predetermined portion of said status information upon trans- 
fer of said first predetermined segment of said first prede- 
termined data stream between said buffer pool and a first 
memory space. 

3. The bus transfer control system of claim 2 wherein said 
plurality of data transfer devices includes a second data 
transfer device coupleable to a second memory space and 
responsive to the access availability of said second memory 
space and wherein said second data transfer device obtains 
a second predetermined portion of said status information 
stored by a second bus transfer unit by obtaining program- 
ming from said transfer controller, said second data transfer 
device updating said second predetermined portion of said 
status information upon transfer of a second predetermined 
segment of a second predetermined data stream between 
said buffer pool and said second memory space. 

4. The bus transfer control system of claim 3 wherein said 
first and second predetermined data streams are the same 
data stream, 

5. The bus transfer control system of claim 3 or 4 wherein 
said status information is stored as a plurality of bus transfer 
units in a bus transfer table and includes prioritization and 
memory buffer information and wherein said transfer con- 
troller is coupled to said bus transfer table for iteratively 
selecting highest priority first and second bus transfer units 
for respective use by said first and second data transfer 
devices. 

6. The bus transfer control system of claim 5 wherein said 
transfer controller maintains respective identifiers of said 
first and second bus transfer units for use in updating said 
first and second bus transfer units independent of a next 
iteration of selecting said highest priority first and second 
bus transfer units for respective use by said first and second 
data transfer devices. 

7. A bus master data transfer control system for transfer- 
ring data segments of multiple continuous transfer data 
streams between a memory accessible by said bus master 
data transfer control system over an arbitrated access data 
transfer bus and a buffer pool, said bus master data transfer 
control system comprising: 

a) a buffer pool providing for the storage of a plurality of 
data packets; 

b) a first bus master unit coupleable to a first arbitrated 
access data transfer bus that provides access to a first 
external memory space, said first bus master unit pro- 
viding for the transfer of a first redetermined data 
packet between said first arbitrated access data transfer 
bus and a first bus master data packet buffer and 
between said first bus master data packet buffer and 
said buffer pool; 

c) a second bus master unit coupleable to an second 
arbitrated access data transfer bus that provides access 
to a second external memory space, said second bus 
master unit providing for the transfer of a second 
predetermined data packet between said second arbi- 
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tratcd access data transfer bus and a second bus master 
data packet buffer and between said second bus master 
data packet buffer and said buffer pool; and 
d) a bus transfer controller, responsive to the data segment 

s present statuses of said first and second bus master data 
packet buffers, including a table for storing bus transfer 
control units including first and second predetermined 
bus transfer control units that respectively determine 
bus master data transfers by said first and second bus 

10 master units relative to said buffer pool, said bus 
transfer controller iteratively operative to select a pri- 
oritized bus transfer control unit from said table to 
enable a bus data transfer relative to said buffer pooL 

8. The bus master data transfer control system of claim 7 
IS wherein said first and second predetermined bus transfer 

control units are programmaticalry associated with said first 
and second bus master units and a predetermined memory 
block of said buffer pool. 

9. The bus master data transfer control system of claim 8 
2Q further comprising an arbiter system for selecting either of 

said first and second bus transfer control units for use in 
programming a respective one of said first and second bus 
master units for the transfer of said first and second prede- 
termined data packets. 
25 io. The bus master data transfer control system of claim 

9 wherein said bus transfer controller manages the transfer 
of said first and second data packets through said buffer pool 
and wherein said arbiter system is coupled to said bus 
transfer controller for toennining the selection of said first 

30 and second bus transfer control units. 

11. The bus master data transfer control system of claim 

10 wherein said first and second predetermined data packets 
represent individual data packets within a first stream of data 
packets, and wherein a third bus transfer control unit stored 

35 in said table specifies a third bus master data transfer of a 
third predetermined data packet of a second stream of data 
packets. 

12. An I/O channel controller supporting the asynchro- 
nous transfer of a plurality of continuous transfer data 

40 streams between a memory and a plurality of I/O interface 
units* said VO channel controller comprising: 
a) a FIFO pool buffer including a plurality of dynamically 
allocable FIFO buffers through which streams of data 
are asynchronously transferred; 

45 b) a plurality of I/O interface units; and 

c) a transfer control unit providing for the storage of one 
or more transfer control data units, said transfer control 
unit autonomously monitoring the amount of data buff- 
ered by any of said dynamically allocable FIFO buffers 
relative to a predetermined threshold amount and for 
selectively initiating the transfer of portions of said 
streams of data as defined by respective ones of said 
transfer control data units between said memory and 

55 said FIFO pool buffer. 

* * * * * 
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